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c. I 



ABSTRACT 



An introduction to decision loqic table terminology/ 
structure/ theory/ and preprocessor historical development. 
Advantages of decision tables and flowcharts have been sur- 
veyed and contrasted. Techniques of decision table prepara- 
tion have been enumerated. OELTRANS/ a rule mask logic 
table preprocessor for the C language/ has been proposed for 
use on the PDP-11/50 system at the U.S. Naval Postgraduate 
School . 
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I. INTRODUCTION 



A. BACKGROUND 

A decision table preprocessor is a software proqram for 
translating decision logic tables into compilable source 
code* The preprocessor developed by the authors* aptly 
called DELTRANS* was desi nned to operate on the PDP-11/50 
system at the Naval Postgraduate School and accept C 
language programs containing decision logic tables* The 
design of DELTRANS was based on the sequential testing rule 
mask technique perfected by Press [201. 

The use of this decision table processor should reduce 
both programming effort and time. The additional computer 
time required for compilation is overshadowed by the reduc- 
tion in manpower required for programming both during 
initial programming phases and maintenance phases. The con- 
cept and structure of decision logic tables causes the 
number of overlooked situations and program inconsistencies 
to be reduced* 

Decision tables offer a stimulating alternative to 
traditional programming methods for those who are willing to 
educate themselves in their construction and use. With this 
knowledge* DELTRANS is but another tool for the C 1 anguage 
programmer* Possibly a very valuable one. 
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The major steps from program input to production of 
executable code are depicted in Figure 1. Initially/ a file 
containing a C language program may be created at a 
terminal. The programmer codes those segments of the pro- 
gram not covered by decision logic tables. Special symbols 
indicate to the table preprocessor the beginning and ending 
of each table. Otherwise/ the code is passed unchanged. At 
this point/ a call to DELTRAMS is initiated in order to pro- 
duce compilable source code. As shown in Figure 1/ a table 
listing may also oe obtained. Subseauent 1 y / normal program 
compilation may be accomplished. 

Appenoix A, the DELTRANS User's Manual/ was written as 
an independent document and as such/ guides a user through 
the steps illustrated in Figure 1. 

B. HISTORICAL DEVELOPMENT 

1. Development of the First Processor 

In the mid-IRSOs/ General Electric's Manufacturing 
Services Department initiated a research effort to study the 
manufacturing processes that occur from the receipt of a 
customer order through the production of the finished pro- 
duct. Having recognized that computers might play a 
significant role/ a search was begun to find a satisfactory 
method for expression the complex logic encountered. 
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FIGURE 1. DELTPANS Functional Diagram 
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It soon became apparent that available methods of 



describing decisions/ such as formulas# narratives# and 
flowcharts# were inadequate. The efforts of the project 
team to discover a new method of expression culminated in 
the development of "decision structure tables"tl8]. These 
tables had a format similar to the truth tables from which 
they originated. 



The processor for solving these tables# expressed in 
a language called IA9S0L, operated initially on an IBM 702. 
Later it was successively implemented on an IBM 305# 650# 
and 704. In early 1961# an improved version of the proces- 
sor and TABSOL were implemented on the G F. 225. 



Durinq this same time period# Sutherland Management 
Consultants also began experimenting with aecision tables 
[18]. They produced a table different in form but identical 
in concept. The emphasis was olaced strictly on the use of 
decision tables as an aid to systems documentation# leaving 
the solution of the table to the programmer. 

A number of companies# including Hunt Foods# North 
American Aviation# and the Insurance Company of North Amer- 
ica# initiated research on decision tables 1 1 1 J » primarily 
to facilitate in-house file-maintenance and system documen- 
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t a t i on 



From 1960, the CODASYL systems study group has car- 
ried out work on the development of a high-level language, 
COBOL. Decision tables were selected as an addition to 
COBOL and in 1962, the specifications of DETAB-X were pub- 
lished. The manual described a decision table preprocessor 
that could accept the decision tables as input and produce a 
form of COBOL codina as output. This was the first table 
processor available to computer users. 

2. Evolution and Refinement 

In June 1965, the Special Interest Group for Pro- 
gramming Languages (SIGPLAN) of the Los Angeles Chapter of 
the Association of Computing Machinery appointed a working 
group to develop a decision table preprocessor. The result 
was the distribution of DETAR/t>5, written in a restricted 
subset of COBOL. Although implemented on the CDC 3600 and 
IBM 7094, among others, its inefficient conversion algorithm 
led to its dem i se . 

It has become evident that DETAB/65 was, however, 
the ancestor of the current group of proprietary decision 
table preprocessors developed since 1966. Generally, the 
processors follow the DETAB/65 lead in that they are a 
preprocessor written in COBOL that converts decision tables 
containing COBOL components to a stream of COBOL source code 
suitable for compilation. There are several exceptions to 
this basic rule. 
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IBM's System/360 Decision Logic Translator processes 
decision tables coded in Fortran. There are also other not- 
able examples using BASIC and ALGOL 1153 * Some 
preprocessors offer the programmer the option of specifying 
the language to be processed. 

3. Use Today 

A review of decision loaic table preprocessor his- 
tory almost forces one to wonder why decision logic tables 
are not universally used for systems analysis/ program 
development/ and documentation. Many times/ this technique 
has succeedeo where the more widely used methods of narra- 
tive and flowcharting have failed. why then has the use of 
decision logic tables not been more widespread? 

Three oossible causes have been identified. First/ 
the amount of information available to systems analysts and 
programmers on a daily basis has been limited. Although 
many articles have been published over the years/ they have 
generally appeared in hiqhly technical form or have appeared 
in proceedings or journals not extensively circulated to the 
commercial practitioner. As a rule, decision tables have 
not been tauaht in their rightful place as an alternative to 
flowcharts in introductory programming courses. 

Second* the use of decision tables requires a dif- 



ferent approach to problem solving than does flowcharting 



Flowcharting leads one to adopt a sequential model of dec i - 
si on making. That i s / a test followed by one or more 
actions. On the other hand/ decision logic tables require 
an overall analysis of the conditions that comprise a given 
problem and the effect of their various combinations on the 
solution. Naturally/ there is much resistance among those 
trained in sequential type analysis to accept a new tech- 
nique. 

Third/ there has been a general lack of decision 
table processors available to the data processing community. 
As a result/ tables had to be hand translated to sequential 
code for input to the computer. Absence of a mechanized 
means of translation has resulted in a rapid decrease of 
interest in decision tables by programmers. 



These three conditions are slowly being eased with 
the increase of books and articles published on the subject. 
Seminars are available from several sources and presumably/ 
the Historical resistance to decision tables will be over- 
come . 



C. FLOWCHARTING VERSUS DECISION TABLES 

As has been pointed out/ narratives and flowcharting 
have historically been used to document computer programs 
and structure their logic. These techniques have been 
demonstrated to be very effective time and time again/ as 
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long as the problem remained relatively simple and straight- 
forward. However, this effectiveness has severely 
deteriorated when the problem became more complex. 

Decision logic tables have been shown to provide a for- 
mat for organizing and displaying program logic* and have 
been compared with narratives and flowcharts in program 
documentation and logic structuring. This comparison has 
shown a number of important advantages and disadvantages of 
the use of decision logic tables. 

One advantage of decision logic tables over other forms 
is the conciseness normally associated with a decision 
table. A much larger amount of information may be placed in 
a given space using a table as opposed to narratives or 
flowcharts. This dense display of information provides a 
much clearer r eo resen t a t i on of the proqram loqic than a 
cloudy narrative or a branching, meandering flowchart. 

The conciseness of decision logic tables leads directly 
to their second advantage. Namely* the advantage of 
thoroughness or completeness. The person preparing decision 
logic tables is forced by their format to consider all pos- 
sible combinations of events. This is quite different from 
the flowcharting approach which tends to emphasize sequen- 
tial logic flow. This emphasis on sequential logic flow 
often tends to obscure alternative logic* and may thoroughly 
avoid the issue of loaic completeness. Failing to be 
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prepared for all possible combinations of events is of 
course a major source of subtle program "bugs". 

Non-sequen t i a 1 logic f 1 ow also tends to assist the pro- 
grammer in eliminating other logic errors. The elimination 
is due to the manner the entire flow of logic is displayed 
at a glance in the case of decision logic tables. The pro- 
grammer is thus permitted to visualize better the interrela- 
tionships and alternatives within the problem at hand. Not 
only is completeness displayed but also redundant tests are 
pinpointed thus permitting the production of more efficient 
code . 



Dec i 


sion logic tabl 


e construction 


and 


mod i f i c a t i on 


i s 


easy to 


learn. Thus # a 


non-orogrammer 


can 


normally read 


the 


logic of 


a well written 


program. Further* 


deoendenc y 


upon 



the oriainal programmer is greatly reduced since modifica- 
tions are easy to perform. 

A final important advantage of decision logic tables 
over flowcharting is their ability to serve as computer 
input. This permits machine checking for certain types of 
logic errors and mechanized conversion into a program seg- 
ment . 

Several disadvantages to the user of decision logic 
tables do exist. Perhaps the most insidious is that the 
seguential flow of flowchart inq has been the only technigue 
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taught programmers. The effort to learn something "new" has 
only been reluctantly taken in may cases. 

Another drawback is that althouah it is easy to learn to 
use decision logic tables* extensive work is required to 
become truly efficient in programming with them* as opposed 
to programming with flowcharts. when using a computer to 
convert the logic* further work is required to become 
familiar with the translator or preprocessor. 

Even though the flow of logic is improved* the actions 
specified cannot be machine checked to ensure they are 
correct* or even feasible for that matter. Also* the 
machine is incapable of recognizing impossible combinations 
of events. This forces the programmer to perform these 
checks or supply some escape set of actions. 

The advantages and disadvantages of decision logic 
tables discussed here have been summarized in Table t. They 
may be compared with those of flowcharts that have been 
listed in Table 2 . 

Clearly* decision logic tables are not a panacea for all 
the ills of data processing today. However* they can be 
used as a very effective tool to ensure proper program logic 
flow and should be used in conjunction with narratives and 
flowcharts* as aporopriate. 
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advantages 



1. Clear enumeration of all operations performed. 

2. Clear identification of the seauence of operations. 

3. Easily learned. 

4. Effective means of communication between people in and 
out of data process i no. 

5. Concise and compact form of documentation. 

6. Easy to construct/ modify and read. 

7. Easy visualization of relationships and alternatives. 

8. Directly adaptable to computer operations. 

DISADVANTAGES: 

1. May be larqe for complex situations. 

2. Multiple tables may be needed. 

3. Graphic display of flowcharts may be more meaningful. 

4. Requirements too detailed for man-to-man communication. 



TABLE 1. Advantages and Disadvantages of Decision Tables 
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ADVANTAGES 



Easily produced. 

Easily lea rned • 

Can describe data handling and computer operations. 
Can be produced by computer alaori thms from source 

t 

programs • 



DISADVANTAGES: 

Heavily influenced by personal preference. 

May be difficult to follow in complex problem. 
Revision is difficult. 

Limited in displaying all logical elements. 
Detailed logic flowcharts are unwieldy. 



TABLE 2 . Advantages and Disadvantages of Flowcharts 



DECISION TABLE STRUCTURE 



I I . 



This section is intended to introduce decision logic 
tables by describing their structure and the rules governing 
their use. Simply stated; a decision logic table is a 
tabular representation of all elements of a problem from 
conception to solution. Information displayed in this 
manner is easily comprehended even when the table of infor- 
mation represents a complex logical problem. The logic used 
in decision tables is similar to that which is used every 
day# with or without the aid of the computer. 



A. THE ELEMENTS OF A TABLE 

Before describing in detail the table itself; several 

V 

definitions must be made clear. First; a decision rule is a 
statement that prescribes the set of conditions that must be 
satisfied in order that a series of actions be taken. For 
example; the following is a decision rule: 



If a laborer works more than 40 hours in a week, 
he must be paid his reqular salary rate plus the 
product of hi. s overtime hours times his hours in 
excess of 40 . 
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The decision logic table is used to describe the possible 
decision rules derived above. That i s» whether or not the 
laborer worked more than 40 hours in a given week. 

The decision table itself is a structure for describing 
a set of related rules. Althouqh other formats of decision 
tables exist? some of which are easier to use [18]? they are 



permutations of the basic 


format shown in Fiaure 


CONDITION 


CONDITION 


STUB 


ENTRY 


ACTION 


ACTION 


STUB 


ENTRY 







FIGURE 2. Decision Table Structure 



A s illustrated? the table is divided into four 
quadrants. The upper left Quadrant / called the condition 
stub? contains all the conditions oeing considered for a 
particular decision rule. The condition entry? in the upper 
right quadrant? combines with the condition stub to form the 
condition that is to be tested. 
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In the lower left quadrant* is the action stub. It con- 
tains a simple statement of the actions resulting from from 
the conditions listed above the horizontal line. Action 
entries are displayed in the lower right quadrant. In this 
quadrant* the appropriate action resulting from the various 
combinations of responses to the conditions will be indi- 
cated. 



As 


shown in Figure 3* 


the table 


a 1 so 


contains a 


sect 


i on 


cal led 


a table header. 


Actually* 


this 


ident i fying 


data 


i s 


required in order to distinguish it 


f r om 


all other tables 


i n 



a given job. 



TABLE HEADER RULE HEADER 





R1 


R 2 


R 3 


R4 


Cl 










C2 










C3 










A1 










A2 










A3 











FIGURE 3. Basic Elements of a Decision Table 



22 



The information that might he found in a table header 
includes a table number/ a table name/ the table type/ the 
number of rules/ conditions and actions/ and any other 
options locally established to simplify translation. 

The various' combinations of responses to conditions 
shown in the condition entry quadrant are called rules or 
paths. Each is given a number for identification purposes 
in the rule header oort i on of the table. 

B. TABLE ENTRIES 

1 

If a condition in the condition stub is true/ a Y is 
entered for that particular rule in the condition entry. 
Conversely/ if the condition is false/ an N would be 
entered. Ahere irrelevant situations occur/ a "don't-care" 
is indicated by a dash (-). 

Additionally/ two other entries have been proposed to 
indicate mutual exclusion of one condition with another 
[18/81. If the case arises within a single rule that the 
satisfaction of some test/ indicated by a Y or N entry/ 
makes some other entry a foregone conclusion/ then the 



special 


entries 


» * 1 


or 'S' may be 


used 


t 0 


indicate this 


fact. 


The symbol 


1 * 1 


is used in place 


of an 


N 


entry 


unde r 


these 


c i rcumstances/ 


while the ' $ ' is 


used 


i n 


place 


o f a Y 



entry. 
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The network algorithms and several sophisticated algo- 
rithms that attempt to minimize execution time of the 
translated table and/or provide completeness checking make 
excellent use of these implied truth values. Those algo- 
rithms provide completeness checking which accounts for the 
logically impossible rules introduced by condition depen- 
dency. 

In the action entry quadrant » an X is entered to indi- 
cate that action which is to be executed for a particular 
rule. Any given action may be executed for any number of 
rules* however a rule may reguire more than one action and 
where an X is entered for each action in the action entry 
quadrant . 

C. TYPES OF TABLES 

There are three types of decision tables in current use. 
The limited entry table is the most popular and most often 
used (8). Since the other two table types* extended entry 
and mixed entry, may always be transformed into limited 
entry tables* the preprocessor developed here allows only 
limited entry table input. The other two types of tables 
will be discussed, however. 

1. Limited Entry Tables 

The rules regarding the placement of information in 
each of the four cuadrants of a limited entry table are 



fixed and inflexible. The condition and its state must be 
restricted to the condition stub. The condition entry may 
only show the resDonse Y (true)/ IM (false)/ * (implicit N)/ 
$ (implicit Y) or (don't care). 

Likewise/ specific actions must be fully identified 
within the action stub and permissible notations within the 
action entry sections are limited to an 'X' or a blank. 

Table 3 shows a limited entry table in. proper for- 
mat. Note that entries orescribed for one quadrant may not 
extend into another and that every condition entry contains 
one and only one of the allowed symbols. Normally/ limited 
entry tables are the best suited to computer applications 
(1 31 . 



LOAN TABLE 


R1 


R2 


R3 


R4 


SATISFACTORY 
CREDIT LIMIT 


Y 


Y 


N 


N 


FAVORABLE 
PAY EXPERIENCE 


Y 


N 


Y 


N 


APPROVE LOAN 


X 




X 




REJECT LOAN 




X 




X 



TA8LE 3. Limited Entry Table 
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Extended Entry Tables 



In extended entry tables, the variables to be tested 
are identified in the condition stub, while the condition 
entry must define the value or state of the variable. Like* 
wise, in this type of table, the action stub names an action 
while the action entry will give the specifics for the 
action named. 

As shown in table 3, the format is not quite as 
strict for this type of table. The use of this format may 
also tend to decrease the number of items in both the condi- 
tion and action stubs. 



LOAN TABLE 


R1 


R2 


R3 


R4 


CREDIT 

LIMIT 


OK 


OK 


TOO 

LOW 


TOO 

LOW 


PAY 

EXPERIENCE 


OK 


POOR 


OK 


POOR 


LOAN 


APPROVE 


REJECT 


APPROVE 


REJECT 



TABLE <4. Extended Entry Table 
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3. Mixea Entry Tables 

i 

The mixed entry table is a combination of the lim- 
ited entry form and the extended entry form. Even though 
these two forms may be combined/ one form must be used 
exclusively within each horizontal row of a table. Table 5 
depicts the information from the previously used tables as a 
mixed entry table. 



LOAN TABLE 


R1 


R2 


R3 


R4 


CREDIT LIMIT 


OK 


OK 


TOO 

LOW 


TOO 

LOW 


FAVORABLE 
PAY EXPERIENCE 


Y 


N 


Y 


N 


APPROVE LOAN 


X 




X 




REJECT LOAN 




X 




X 



TABLE 5. Mixed Entry Table 
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III. DECISION TABLE THEORY 



The uses for decision tables vary greatly throughout 
the fields of business# science# and engineering. Whatever 
their purpose# a sound theoretical basis is needed to 
explore further the intricacies of their potential. This 
section is dedicated to fulfilling that need with a general 
overview of the background theory of decision logic tables 
and specific treatment of rule mask theories. This discus- 
sion is a prelude to the tooics of table completeness and 
decision rule contradiction and redundancy. 

A. GENERAL 

As previously stated# a decision table is made up of a 
set of conditions# each of which may be evaluated as true or 
false at any given time. The truth or falsity of these con- 
ditions may be combined in various ways# along with a series 
of actions# to form a decision rule. 

The series of actions contained in a particular decision 
rule are executed when a transaction is evaluated that 
matches the particular combination of truth or falsity of 
the conai t ions indicated by the Particular rule. 
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The decision tables presented here are based on one of 



the Boolean algebra functions known as the AND function. It 
is considered to be the ordered set of V's» N ' s / or dashes 
that appear as the condition entries for a particular deci- 
sion rule. The aoolication of the OR function can also be 
made in decision tables and it is described in some detail 
by Pollack/ et al.tlBJ. 

In order to illustrate the AND function/ the following 
table is presented with its associated AND functions. 





R1 


R2 


R3 


R4 


TYPE >60 WPM 


Y 


Y 


Y 


N 


SHORTHAND >90 


Y 


Y 


N 


— 


SALARY 5 $5500 


Y 


N 


— 


— 


HIRE 


X 








DO NOT HIRE 




X 




X 


REFER TO 
TYPING POOL 






X 





AND function 1 = Y , Y , Y 

t 

AND function 2 = Y/Y/N 
AND function 3 = Y / N , - 
AND function 4 = N / - / - 

FIGURE 4. AND Function Examples 
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Basically* to determine whether or not a decision rule 
is satisfied* evaluate the AND function for that rule* and 
check that it eaual s the reaui red transaction. For example* 
the AND function of rule 3 would be satisfied if the job 
applicant could type 60 or more words per minute but could 
not take dictation at a speed greater than 90 words per 
minute. For this rule* condition 3* the possible salary* is 
of no conseauence to the ultimate satisfaction of the rule. 



B. CONDITIONS 



So far* the word condition has been used numerous times 
without a complete definition. A condition is a variable 
factor affecting the action(s) to be taken in a given s i t u a - 
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9 



1 



" C "* etc.* present in the table. 

2 

hihen a table is evaluated* the various conditions are 
found to be either true or false. This truth value is 
stored in a matrix M according to the following code pro- 
posed by Press(20], 



M 

i 9 1 


= 1 and 


M 

i 


= 0 

*2 


implies the 


condition 


i s t rue 


M 

i 9 1 


- 0 and 


M 

i 


= 1 

*2 


implies the 


condition 


is false 
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Therefore^ for N conditions the following matrix M would 



be formed: 



M 


M 


1 , 1 


1,2 


M 


M 


2, 1 


2,2 


M 


M 


3, 1 

. 


3,2 

. 


. 

. 

M 


. 

M 


n » 1 


n / 2 



Each vector of the matrix thus formed is called a mask. 



1. Structure of Conditions 

Each condition is most often made up of two operands 
related by a relational coerator. For inout to the prepro- 
cessor developed here/ the conditions must each be grammati- 
cally correct C language expressions. For instance/ in its 
most basic form/ one operand in a condition statement must 
be a variable/ while the other may be a constant or vari- 
able. The relational operators may be any one of the fol- 
lowing C language operators: 

= = <= > = < > i = 



For example/ consider the following three conditions 
in which a variable is compared to an integer: 



3) 



x < 10 



C : 
1 



C : y >= 15 

a 



C : z 1= 0 

3 



At the time of evaluation, the truth value is determined for 

each C . Given that x ~ 5 , y = 20, and z = 0, the following 
i 

matrix containing two mast’s would be obtained: 



1 0 
1 0 
0 1 



Condition statements may also be made up of 
subroutine calls or variables or even any combination of 
these seoarated by logical operators. They must, however, 
evaluate as logically true or false. 



2. Condition Oeoendency 



Between any two pairs of conditions, there exists 
either dependence or independence. Basically, two condi- 
tions are dependent if they both have the same condition 
variable as an operand. Conversely, two conditions are 
independent if there is no common condition variable used as 
an operand. 
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There are two types of dependence* Firsts there is 

mutual exclusion dependency* This case occurs when for any 

pair of conditions C and C / there is no value of the com- 

i j 

mon condition variable such that their mask entries are both 
equal "I/O'*/ true* However/ this is not to say that both 
conditions may not be false at the same time* 

By extent ion to more than two conditions/ it may be 
said that any number of conditions are mutually exclusive if 
at any point in time every two conditions in each of the 
pairs of conditions are mutually exclusive* 

The second type of dependency is termed overlapping 
deoendency. Overlaoping dependency occurs when there can 
exist at least one value of a condition variable common to a 
pair of conditions such that both conditions are true. 
Other combinations of truth and falsity may also occur. 
Condition dependency thus dictates that certain combinations 
of condition values are impossible events. These impossible 
events represent imoossible rules and need not be considered 
by the proarammer when describina the program logic. How- 
ever/ machine checking for condition dependency is seldom 
implemented in translation algorithms* This causes the 
machine to interpret the decision logic table as being 
i ncomp 1 et e . 
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3 . Condition Entry Notation 



The condition entry portion of a decision table con- 
tains one of the following entries for a condition C # which 

i 



have the meaning given: 



• Y 1 - > C is required to be true, 
i 

, N* => C is reouired to be false 
i 



=> C is immaterial, 
i 



=> C is false# if some other explicit 
i 

condition is proven. 



'$• => C is true# if some other explicit 

i 

condition is oroven. 

In the arguments to follow# the dash or ' - ' will be 

denoted by I for a condition C # where the condition is 
i i 

immaterial and C neeo not be proven either true or false. 

i 

Also# it should be pointed out that 



I = Y + M 
i i i 

where + is an inclusive OR 

Analogously# the symbols * * * and 1 $ * indicate that 
the condition they represent need not be proven false or 



3a 



t rue 



. They implicitly represent both Y and 

i 

t i on C and thus have the full power of both 
i 



C. AND FUNCTIONS 



N for a condi - 
i 

if tested. 



In the discussion to follow# an AND function# 
be considered to be defined as: 



B , 

j 



will 





B 


= W 


& W KM & ... . 


. & 


I'J 




j 


1 , 


j 2 , j 3 , j 




n f ) 


Where W 

i 

condition 


is a vector 


representing any one 


0 f 


the possible 


entries 


for condition i and 


' & ' 


is the Boolean 



operator AND. 



Each independent condition may reouire W to be Y # N # 

i i i 

or I • Dependent conditions may take on the implicit 
i 

requirements * and $ # but these are special cases of Y 
i i i 

ana N # respectively. Therefore W may be expressed in one 
i i 

of three states: Y $ N or I • Thus# the number of oossi - 

i i in 

ble forms of an AND function is 3 • 



Recall that the matrix M represents the truth or falsity 
of n conditions. Given a particular matrix M , it may be 
determined for M whether V(B ) # the logical value of B # 

j j 

equals 1 or 0 by first makino appropriate entries for each 

to of 8 # according to the rules indicated in Figure 5. 
i ' j J 

For example# suppose 



and 



B = (Y Y N ★ I Y) 
j 
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1 



0 



M 



0 1 
0 1 
1 0 
0 1 
1 o 



Then/ according to the replacements indicated in Figure 
5/ we have 



e =(ioiiin 

j 

\ 

Therefore^ V(B ) = 0. Had the resulting B contained all 

j ] 

1 ' s / the logical value/ V(9 )/ would have been 1. 

j 



w 

* ' j 



Y 

Y 

N 

N 



* 

S 

S 

I 



I 

FIGUPE 5. Table of 



V(C ) 
k 

0 1 
1 0 
0 1 
1 0 
0 1 
1 0 
0 1 
1 0 
0 1 
1 0 

Reol acements 



Replace with 



0 

1 

1 

0 

1 

1 

1 

1 

1 

1 

for Determining V(B ) 



j 
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As an example? consider again the following conditions 



C : x < 10 

1 



C : y >= 15 

2 



C : z I = 0 

3 



Given that x = 5? y = 20? and z = 0? the following matrix 
was obtained: 

1 0 
1 0 
0 1 



From a typical decision table that may be easily formed? the 

following AND function is oresent: 

e = (Y Y Y) 

1 

Again? according to the replacements indicated in Figure 
5 ? we obtain 



R =(110) 

1 

And V ( B ) = 0. The first AMD function tested is not satis- 

1 

f i ed and its associated action(s) will not be done. Another 

/ 

function must be considered, 

1. Dependency of AND Functions 

Dependency among AND functions is somewhat different 

than that among conditions. Two AND functions# B and B # 

i j 

are dependent if for at least one set of values of the 

conditions variables and reau i remen t s # both V ( B ) = 1 and 

i 



37 



V ( B ) = 1. Otherwise# the AND functions are independent and 

j 

no one set of the conoi t i on variables set V C B ) and V ( B ) to 

i j 

1 . 



For example# consider the following two AND func- 
tions: 



B = Y , Y # Y , N 
3 • 



B = Y , Y , Y , N 
a 



Then for a set of values of the condition variables that 
yields 



1 0 



M 



0 



1 0 
0 1 



both V ( B ) = 1 and V ( 8 ) = 

3 a 

dent. Had either V(B ) 

3 

would have been founo to be 



. Thus# B and B are depen- 
3 a 

= 0 or V ( B ) = 0, then B and B 
a 3 a 

independent . 



2 . Definitions 



A cure AND function is one that contains no "I" 
entry. For example# 

P = Y , * , S 

is a pure AND function. 
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A decision rule is simple if it contains a cure AND 
function. A mixed AND function is one that contains one or 
more I's. A decision rule is complex Cor compound) if it 
contains a mixed AMD function. 

D. THEOREMS FOR AMD FUNCTIONS 

In the theorems that follow* a table* T* is assumed to 
comprise all AMD functions that can generate from the condi- 
tions of that table. The theorems are presented for infor- 
mational purposes only. Detailed proofs are presented by 
Pollack 1181. 

THEOREM I. Within table T* two AND functions are 
independent if* in at least one position* one func- 
tion contains a Y and the other function contains a 
N. Otherwise* they are dependent. 

For an illustration of theorem I* consider the following 
incomplete table. 




least one Y * N oair for the three conditions. 



3R 



A F 2 and A F 3 are independent because a Y , N pair exists 



for condition C . 

2 

THEOREM II. Within table T, each pure AND function 
is independent of every other pure AND function. 

Consider the following table for an illustration of 
theorem II. 





AF1 


AF2 


AF3 


AF4 


Cl 


Y 


Y 


N 


N 


C2 


Y 


N 


Y 


N 



By definition, all four AND functions are pure. From 
theorem I, they are independent. In this example, there are 
no other pure AND functions possible and therefore each pure 
AND function is independent of every other pure AND f unc* 
t i on . 



THEOREM III. Within table T, every mixed AND func~ 

tion that contains I in positions (1 < = r < n) is 

r 

dependent on each of 2 cure AND functions of T. 



Consider the followino partial table. 




ao 



-‘V 



API expands to contain the following pure AND functions 



AFla 


AFlb 


Y 


Y 


N 


N 


Y 


N 



Referring to theorem 1/ AF1 is dependent on AFla and 
AFlb. 

THEOREM IV* Table T / based on n conditions* con- 

n 

tains one* and only one* set of 2 independent Pure 
f unc tions. 

As an illustration of theorem IV* consider the following 
table* 





AF1 


AF2 


AF3 


AF4 


AF5 


AF6 


AF7 


AF8 


Cl 


Y 


Y 


Y 


Y 


N 


N 


N 


N 


C2 


Y 


Y 


N 


N 


Y 


Y 


N 


N 


C3 


Y 


N 


.Y 


N 


Y 


N 


Y 


N 



With the total number of conditions eaual to 3* the 

3 

total number of pure AND functions should be 2 = 8* accord- 

ing to theorem IV. As can be seen above* no other pure AND 
function exists that does not duplicate one of those in the 
table. 
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THEOREM V 



Any decision rule that contains I in r 



positions (0 <= r < n) of 'its AND function is 

, r 

equivalent to 2 simple decision rules. 

Theorem V is illustrated by the following oartially com- 
plete table. 




The comole* decision ruler Rlr is ecu i valent to 2 = 2 
simple decision rules/ Rla and Rib/ both of which contain 
pure decision rules. 



Rla 

Y 

Y 

X 



Rib 

Y 

N 



X 



IV. PREPARING DECISION TABLES 



A. BASIC TECHNIQUES 

This section Dresents two methods for the development of 
decision tables. The classical techniaue and the progres- 
sive rule development techniaue# both of which follow the 
formal preoaration rules presented in an earlier section. 

In the classical techni aue< all Possible combinations of 
conditions are considered and a matrix is produced in the 
condition entry which represents all possible simple rules. 
Next» the table is simolified by repeatedly combining 
several simple rules into a complex rule# thereby producing 
fewer rules. The process becomes almost mechanical# how- 
ever# and it is possible to lose sight of the total problem 
logic. 

The other method# by progressive rule development# is 
based on formalized rules adapted from flowcharting. The 
logic of the problem is considered step Dy step and the 
table prepared as the problem is studied. Normally# this 
method is somewhat faster than the classical one. Because 
the development of the table is in step with the loaical 
analysis of the problem# the total logic can always be seen. 
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It should be oointed out here that the form of the deci- 



sion table should reflect its ultimate use. When preparing 
a decision table for preprocessing, compact, sophisticated 
logic should be reflected in the table. Alternatively, if a 
table is to be used purely for documentation purposes, it 
would be best for the table to be laid out in a simple, 
easily readable form. The fact that oversophistication in 
compressing logic and in minimizing the number of rules pro- 
duces a table which is more difficult for the ultimate user 
to understand should be kept in mind. Furthermore, if care 
is not used, errors may inadvertantly be introduced. 

B. CLASSICAL TECHNIQUE' 

The classical techniaue emphasizes the development of a 
matrix represent i no all the simple rules for the given con- 
ditions. Then the full matrix will be reduced, if possible, 
to a fewer number of rules by combining the simple rules to 
form complex rules. The following seven steos may be fol- 
lowed almost mechanically to produce a logically correct and 
relatively concise table. 

1. List all conditions 

2 . List all actions 

3. Complete condition entry (for full matrix) 

4. Complete action entry 






5. Consolidate and form complex rules 



6. Check table 

7 . Transcribe final version and recheck 

This techniaue can be used for all three types of tables 
(limited/ extended/ and mixed entry). Each of the seven 
steps will be described in the following sub*sect ions. 

1. List Conditions 

By thorough study of the problem under considera- 
tion/ all the relevant conditions may be determined and 
listed. At this Point/ the statement of the condition 
should be as clear and concise as possible. In order to 
avoid logically correct/ but complicated statements/ nega- 
tive expressions should be avoided whenever possible. A 
negative statement relies on a double negative for the posi- 
tive case. For example/ the condition "no soace available" 
gives Y (out of space) and N (soace available). 

As a general rule/ conditions which are not indepen- 
dent should also be avoided. Often/ where one condition 
includes another/ there may be some misunderstanding of the 
problem at hand. Conditions which are not independent pro- 
duce impossible rules and incomplete logic tables. 

Loaically/ the sequence of the conditions tested 
does not affect the validity of the table/ but it does 
affect the ease of reading and table construction. The 



basic guide to follow is to list conditions in order of most 



likely satisfaction. When their relative likelihood is not 
known/ listing in the sequence in which identified is a good 
starting point. It is imperative to list all possible condi- 
tions before proceeding to the next step. 

\ 

2 . List Actions 

Listing the actions next allows a double check to 
ensure that all the conditions have been listed. Action 
statements are generally easier to formulate than condition 
statements and are generally given as some sort of command. 
For convenience/ actions should oe listed in the sequence in 
which they are to be performed. This rule is mandatory when 
advanced techniques/ such as recursion or table linkage/ are 
utilized. 

3. Complete Condition Entry 

At this step/ the condition entry part of the table 
is filled in. The object here is to state all the rules 
which represent all combinations of conditions with no 



repet i t i 


on 


o r 


omission of 


any combination. 


As 


previously 


s t a t ed r 


for 


a 1 


imited entry 


table there are 


1 1 

2 


simple 


rules/ 


where n 


i s 


the 


number of conditions. 












At 


the 


cone 1 us i on of 


this step/ a 


comp 1 e t ed 


mat r i x 


is formed 


i n 


the condition 


entry portion 


o f 


the 


table con- 


si st inq 


o f 


al 1 


the ooss i b 1 e 


simple rules. 




I f 


the 


above 



procedure is followed/ each rule will 



be unique ana all 



rules will contain every combination of conditions. 

4. Complete Action Entry 

At this ooint/ each rule is examined. The condition 
entry is considered and the appropriate actions indicated. 
Any action reaui red must be consistent with any other action 
required. In the event contradictions among actions can be 
identified at this Doint » they must be resolved by specify- 
ing an appropriate error action. Above all/ it is vital to 
be consistent in handlinq any ambiguous combination of con- 
ditions. 



5. Consolidation 



In consol idatina a limited entry table/ consider two 
rules with identical actions at a time. For each pair/ the 
two rules may be consolidated if all the condition values 
are the same except one oair. For the condition with the 
unmatched oair/ a dash is entered. This one complex rule 
then replaces the two simple rules. Continuing in this 
manner will result in a smaller/ more manaqeable table. 

6 . Check Table 

At each of the stages previously described/ the work 
done on the table should be checked. The earlier an error 
is detected/ the easier it is to rectify. The checks that 
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should be applied fall into two broad categories: checking 
for content and checking for structure. 

Checking the content should ensure that the action 
entries associated with each simple rule on the unconsoli- 
dated table are correct. Checking the structure of the 
final table is an attempt to ensure that the table contains 
no contradictions or redundancies. 

7 . Make Final Version 

Once a table has been checked/ it may be necessary 
to transcribe it to produce a final version which can then 
be used. The condition and action stubs should be checked 
to make sure that they are clear. 

Normally/ the conditions are listed so that those 
with the most "don't care" entries are at the bottom of the 
list. Similarly/ the seouence of rules can be altered so 
that those rules containing the most "don't care" entries 
appear first. Large tables may be divided into smaller por- 
tions for checking. 

C. PROGRESSIVE RULE DEVELOPMENT TECHNIQUE 

Progressive rule oevelooment is based on standard tech- 
niques for preparing flowcharts. Whereas the classical 
techniaue requires that all possible combinations of condi- 
tions be defined/ progressive rule development requires that 
conditions be written on the table as they are identified. 
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Each rule, including the action entry, 



is entered as the 



problem is analyzed. 

The orocedure for progressive rule development as pro- 
posed by London [111 is enumerated below. Note that the 
steps are repeated until the complete table has been formed. 

flhen all possible conditions have been considered, the 
table should be checked for contradictions and redundancies. 
The following sub-sections point out the major points to be 
kept in mi no at every step. 

1. Consider a Condition 

At this point, a condition should be clearly entered 
into the condition stub. As a starting point, enter a Y 
(true) response in the condition entry adjacent to the con- 
dition. 

2. Consider Further Conditions 

Determine what other conditions are necessary before 
action can be taken. They must also be entered in the table 
as in step 1. The action portion of the table may then be 
completed for this newly formed rule. 

3. Form Next Rule 

The next rule mav be formed by transcribing the pre- 
vious rule, changing the last condition entry for which all 
values have not been considered. For examde, the last Y 
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value entered should be chanqed to an N. All values above 
the changed value are kept the same. 

D. AN EXAMPLE 

This section presents a solution to the following samol e 
problem using the classical technique. 

Hiring a Receptionist 

A new receptionist is needed for an insurance 
company. She must be able to type at least 60 
words per minute and take dictation at a minimum 
of R0 words per minute. All applicants should 
be willinq to work for a salary not greater than 
$5500 a year. All applicants who meet typing 
requirements but not the dictation requirements 
will be referred to the tyoing pool. 



The first step is to identify the conditions that must 
be met. They are then placed in the condition stub of the 
decision logic table in some order of precedence (see Table 
6). All possible actions should be placed in the action 
stub next. 
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R1 


R2 


R3 


R4 


R5 


R6 


R7 


R8 


TYPE > 60 WPM 


Y 


Y 


Y 


Y 


N 


N 


N 


.N 


SALARY §5500 


Y 


Y 


N 


N 


Y 


Y 


N 


N 


SHORTHAND ^90 


Y 


N 


Y 


N 


Y 


N 


Y 


N 


HIRE 


X 
















DO NOT HIRE 






X 




X 


X 


X 


X 


FEFER TO 
TYPING POOL 




X 




X 











TABLE o. Hiring a Receptionist 



The number of rules reoui red to consider all possible 
combinations of conditions is: 



n 

N u m o e r of rules = 2 

where n = the number of conditions 
In this case* 8 rules are required/ as indicated in Table 6. 
Note/ however, that rules 5 thru 8 may be combined due to 
the fact that failing the typing condition results in the 
action "Do Not H i r e " in all cases* Thus/ it can be seen 
that the table may be dramatically simplified immediately. 

Further, the table may be reduced to the one depicted in 
Table 7 by noting the fact that upon satisfying condition 1 
but failure of condition 2 , an ability to take shorthand at 
a rate of 90 or more words per minute, results in that 
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applicant beinq refered to the typing pool. Mote that rear- 
ranging conditions in order of least number of don't care 
entries results in the finalr bifurcated form shown. That 
i s t it is arranged whereby each condition has its Y answers 
grouped together and its N answers grouped together to form 
paths. 





R1 


R2 


R3 


R4 


TYPE > 60 WPM 


Y 


Y 


Y 


N 


SHORTHAND >90 


Y 


Y 


N 


— 


SALARY 5 $5500 


Y 


N 


— 


— 


HIRE 


X 








DO NOT HIRE 




X 




X 


REFER TO 
TYPING POOL 






X 





TABLE 6. Hiring a Receptionist - Final Solution 



/ 
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V. PREPROCESSOR DESCRIPTION 



A. THE ALGORITHM 

There were a multitude of different/ sometimes opposing/ 
attributes that the desired alaorithm was to possess. These 
ranged from the traditional considerations of output module 
size and execution soeed to restrictions arising from the 
intended imolementation computer facility. 

The choice of compiler/ interpreter/ or preprocessor was 
resolved in favor of the preprocessor due to the consi dera- 
tions dictated by the gene ra 1 -ou roose / multi-user/ interac- 
tive operating system UNIX [7]/ as implemented at the Naval 
Postgraduate School/ and its suooort of the programming 
language C [23). Precarina either a compiler or interpreter 
would have entailed duplication of that suooort to some 
degree . 

Algorithms have been developed to attempt to minimize 
execution time/ execution module size/ or both [19]. The 
minimization effort arose from the consideration that the 
prepared execution module was to be used repeatedly/ with 
the preprocessor itself being used relatively infrequently 
on individual tables. However/ in the academic situation/ 
the emphasis has been placed on preparing a working module 
rather than preparing a production type module. This 
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indicates that the preprocessor itself will be used rather 



frequently and the output module will be used very seldom. 
This led to the realization that the preprocessor size and 
execution time were of greater importance than output module 
size and execution time. It was therefore considered desir- 
able for the Dreprocessor code to be small in size and quick 
in execution. Further/ the data area of individual users 
was to be relatively small yet still capable of handling 
more than ten to twelve conditions in the decision logic 
table. 

The final attribute of major importance was that the 
algorithm be capable of being implemented with a minimum of 
user skill. It was felt that several sophisticated algo- 
rithms [18/22/28/24], while of major imoortance in both the 
academic and industrial communities/ demanded too much user 
input to be desirable for beginning decision logic transla- 
tor users . 

The various network algorithms described [18/19/28/10] 
were eliminated as a class since the data area available in 
our mini-comouter was insufficient for ten to twelve condi- 
tions and the prenrccessor execution time was estimated to 
be excessive. 

Rule mask algorithms nave been shown to be highly effi- 



cient 


with resoec t 


to storage 


reaui r emen t s 


(execution 


module 


size) 


(19], translator size* 


and execution 


time/ but 


poor 


with 


respect to 


execution 


module run 


time since 


each 



5 



condition had to be tested to prepare the mask and then this 



mask compared with all the rule masks. This objection faded 
when it was recognized that the target user group would* in 
general* be but slightly concerned with performing the sta* 
tistical background work necessary to Provide the input data 
to obtain truly optimal execution time code. 

The rule mask techniaue of Press [20] has been shown to 
be very good with rescect to execution module run time [19]. 
Additionally* the target user group was expected to be capa- 
ble of orogramminc decision logic tables using the input 
reguired by this algorithm with relative ease. 

For these reasons* the choice of an algorithm was that 
of Press [20]. This aloorithm built a rule mask for each 
rule. Code was generated to seguentially evaluate each con- 
dition and construct a test mask from the results. The rule 
masks were then scanned to find one that matched this test 
mask . 



This algorithm* on one hand* did not reguire a large 
data area* which would have been the case with a network 
algorithm. Yet* on the other hand* the programmer was given 
nothing to control execution time of the output program 
other than simol v placing the rules in decreasing order of 
expected frequency of satisfaction. 

In order to provide a smaller preprocessor module to 
document the grammar of the decision logic table* and to 
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simplify any future changes to that grammar* YACC* a 
compiler-compiler developed by Bell Laboratories [61* was 
used in the construction of DELTRANS* the decision logic 
translator proposed here. 

B. GENERAL OPERATION 

As previously stated* DELTRANS was designed to be a 
sequential testing rule mask decision logic table transla- 
tor. This meant that for each decision logic table DELTRANS 
was to prepare a rule mask to match each rule* generate code 
to test each condition seauentially and set a test mask* and 
finally generate code to test the test mask against the rule 
masks* searching for a match. 

To accomplish the enumerated tasks DELTRANS was con- 
ceived to ooerate in five distinct but interdependent 
phases. The five phases were designated cooy* data area 
i n i t i a 1 i z a t i on * data input* computation* and finally code 
generation. Nhen more than one table was to be preprocessed* 
DELTRANS returned to the copy phase. 

As designed* DELTRANS began execution in the copy 
phase. Code was merely transferred from the input to the 
output file* removing comments while searching for the 
first uo arrow (T) not within auotes* which indicated the 
start of a decision logic table. 
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At this point DELTRANS entered the data area initializa- 



tion phase. In this phase/ DELTRANS read a list of user 
options such as the number of actions ( or conditions/ and 
initialized the internal structures in preparation for table 
input. The user was provided with a great deal of flexibil- 
ity in both size and format/ and considerable error checking 
was performed during this phase. 

If all i n i t i a 1 i za t i on input was in order/ the preproces- 
sor proceeded to the third phase/ data input. In this 
phase/ the table was read and its contents sorted and stored 
for the next phases. Once again/ extensive error checking 
was done during this phase. 

'When the final up arrow in a table was read and the data 
input phase complete/ DELTRANS shifted into the computation 
phase. In this phase there were two major events/ ambiguity 
and completeness checking and the construction of the indi- 
vidual rule masks. 

The final phase of code generation was the point of gen- 
eration of both the output code and a formatted decision 
logic table for use in debugging. DELTRANS returned to the 
copy phase to pass on any additional code or prepare for a 
following table. 

All but the final phase of the preprocessing could cause 
fatal errors. If an unexpected end-of-file was encountered/ 
an error message resulted and the output buffers were 
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flushed into the output file. Otherwise* the standard 
recovery technique was to search for the up arrow, which was 
assumed to mark the end of the current table* and then 
restart from the copy phase. 

C. AMBIGUITY AND COMPLETENESS CHECKING 

DELTRANS was designed to perform two distinct types of 
table looic checking for the user, but had no capability of 
correcting any errors exposed during this logic checking. 
Completeness checking was attempted only after the ambiguity 
checking was completed and no errors found. 

Ambiquity checkino, as oerformed by DFLTRANS* was based 
on two fundamental requirements for all decision logic 
tables [19], First/ every rule must have at least one asso- 
ciated action. And second/ each distinct combination of 
truth values for the given set of conditions must satisfy 
exactly one rule. 

The first requirement arises because for every set of 
conditions some action is* in fact* intended or should be. 
Whether that action be return to the calling point in the 
program* halt program execution immediately* or enter an 
infinite no-operation loop* some program action is intended. 

Check inq for redundancy and inconsistency in table con- 
struction has Peen implemented by comparing the rules to 
insure that between each pair of rules there exists at least 
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one condition row with opposing logic entries for the two 
rules. If no opposing logic entries are found* their ident- 
ical actions indicate a redundant table and differing 
actions indicate an inconsistent table. 

Examples of both cases can be readily observed in table 
8. Rules R 1 and R2 are redundant while R3 and R4 are incon- 
sistent. Note that the implicit entries are considered to 
be equivalent to the explicit entries and therefore there is 
a lack of opposing logic entries. 





R1 


R2 


R3 


R4 


Cl 


Y 


S 


N 


N 


C2 


S 


— 


N 


X 


C3 1 


— 


N 


— 


Y 


A1 | 


X 


X 




X 


A2 j 






X 





TABLE 8. Redunoancv and Inconsistency Example 



Only if the input decision loaic table was non-ambiguous 
did DELTRANS attempt to determine if that table was com- 



o 1 et e . 


Comoleteness testing 


on an 


ambiguous 


table is 


unnecessary . 


A S 


orev i ous 1 y 


noted/ 


Pollack/ 


Hicks* and 


Ha r r i son 


[181 


have 


proven that 


each 


decision 1 


og i c table 
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n 

contains 2 independent simple rules/ where n is the number 

of conditions. They have also proven that all rules 
n 

represent 2 simple rules# where n is the number of "don't 
cares" in that. rule. DELTRANS has incorporated these two 
theorems in its completeness testing. 

If a decision logic table contains two or more dependent 
rules it is said to be ambiguous. In that case the two 
theorems on comoleteness would not apply. Therefore the 
ambiguity checking was designed to preceed the completeness 
checking. 

»vhen checking for completeness# the preprocessor was 
designea to scan each rule for a count of the "don't" care" 
entries in that rule. For each rule# 2 was raised to the 
power of this count and the resulting value added to a tally 
sum for the entire table. A'hen all rules had been scanned# 
this tally was compared with the value of 2 raised to the 
number of conditions. If these two were eoual the table was 
complete# otherwise the table was incomplete. 

If an input decision logic table was found to be com- 
plete# the else/error rule can never be satisfied and is 
therefore superfluous. Since# bv design# DELTRANS reguired 
an else/error action# it was necessary to provide the pro- 
grammer with the capability to input a null action (not a 
no-ooe r a t i on ) to be used with complete tables. 
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If the count of simple rules in a decision logic table 
revealed that not all possible rules had been enumerated/ 
the else/error action was examined. If that action was a 
null action/ then DELTRANS was designed to output a warning 
message indicating that an incomplete table had been encoun- 
tered. Of course/ if the program had specified a valid 
else/error action then the decision loqic table is/ by 
default/ como 1 e t e . 
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VI 



CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

Throughout the available literature/ decision logic 
table structure and terminology was found to be rather 
straightforward and standardized/ as presented here. This 
has facilitated the programmer's use and understanding of 
decision looic tables. 

The theory upon which decision logic table construction 
and translation has been based was found to vary between 
extremes. Pollack and- others 118] have presented clear and 
direct foundations for construction and translation. Some 
alaorithms were discovered which were based more on intui- 
tion than theory [28], while others were founded in theory 
so complex that programmers have had difficulty in grasping 
the looic of a given problem [4/22*24). 

The advantages that decision logic tables offer have 
shown that every programmer should at least be introduced to 
decision logic tables and thus be able to use this powerful 
tool. 

Decision looic tables can be a powerful aid in effective 
communicating/ both man-to-man and man - t o -m ac h i ne / in pro- 
gramming/ and in document ina. The format of decision logic 
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tables permits organization and concise visual presentation 
of complex logic. Decision loaic tables also provide the 
programmer with a very effective tool for insuring that the 
program logic is both correct and complete* items that other 
methods tend to obscure. 

Additionally* since decision logic tables are both easy 

to construct and modify* and may be used as computer input* 

/ 

decision Iodic tables* when properly used* can be an 
extremely effective tool for communicating* programming* and 
document i ng . 

Of the many decision logic table translators a v a i 1 - 
able[141* DELTRANS, as orooosed here* was the only known 
available translator desianed for implementation on the UNIX 
timesharing system for the C programming language. 

The ultimate value of DELTRANS lies in its versatility 
of application throughout management* scientific* and 
engineering fields. Decision logic tables themselves pro- 
vide a simple method for recording logic so that all ele- 
ments of a decision are precisely defined. Tables make it 
possible for managers* scientists* and engineers to use com- 
puters directly. Nuch subsequent programming and coding may 
be eliminated. 

DELTRANS* as developed* fills that gap between a C pro- 
grammer with decision tables and the C 1 anguage compiler. 
The Naval Postgraduate School has been provided with a tool 
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for use in introducing students to the use of decision logic 
tables. A tool that until now has not been available. 

B. RECOMMENDATIONS 

Several refinements to DEL TRANS have been suggested to 
further enhance its utility. Prior to enumerating the most 
important of these refinements it should be pointed out that 
each of these requirements conflicts with some of the design 
criteria used in constructing DELTRANS. 

Additional completeness testing and error checking caoa- 
bilities would assist the orogrammer with complex logic. If 
the necessary space and time were deemed appropriate* the 
preprocessor could be so modified to take full advantage of 
the implicit entries during completeness checking. Further 
coding could provide for automatic error correction of a 
number of programming errors* for example combining redun- 
dant rules. 

An alternate conversion algorithm could be implemented. 
By using one of the network algorithms that has been proven 
to provide minimum execution time output* the capabilities 
of DELTRANS would be enhanced. Since the data structures 
for holding the actions* conditions* and rules and for link- 
ing the rules to the actions were built and maintained by 
DELTRANS* the implementation of an additional coding algo- 
rithm would be simplified. However* these algorithms would 
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reauire additional programmer incut and additional time and 
space for the preprocessor. 

If deemed appropriate/ the required increase in size and 
decrease in speed in the preprocessor could be accepted and 
DELTRAMS could be modified to accept extended and/or mixed 
entry conditions. 

A conversational translator could be developed using 
DELTRANS as a base. This would areatly reduce the file 
manipulating reauired of the programmer under DELTRANS. 

A final recommendation is that decision logic tables be 
presented to students as a cart of an introductory computer 
science course. Even if tables must be hand translated/ 
decision looic tables can provide areat assistance to the 
programmer/ whether he be a beginner or experienced. 
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Effective Use of DELTRANS 

DELTRANS is designed to be utilized by those fluent in 
the design and construction of decision logic tables. Those 
without such a background are directed to the appropriate 
sections of the parent thesis itself and Solomon Pollack's 
work Decision Tables: Theory ajn^ Practice [181 for an intro - 
duction to decision logic tables. 

Additionally* some basic familiarity with the UNIX 
operating system is assumed; specifically* using the edi- 
tor, programming in C, and file man i du 1 a t i on . The paper 
"UNIX for Beginners" by Kerniahan [71 is an excellent start- 
ing point. 



Only 


with a 


thorough oraso 


of the concept s 


of both 


dec i s i on 


tables 


and UNIX may 


a user of DELTRANS 


reap its 


intended 


b e n e f i t s 


as described herein. 
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I. INTRODUCTION 



Decision logic tables describe decision rules. A deci- 
sion rule consists of a set of conditions plus a set of 
actions. The relationshio between conditions and actions is 
of the IF-THEN tyoe. More specifically/ if the given condi- 
tions are met/ then the corresponding actions are taken. 

DELTRANS allows C programmers to convert a C program 
containing one or more decision logic tables into a C source 
program ready for compilation. 

The user needs only a basic knowledae of the C language 
in order to use DELTRANS. The decision table input/ nested 
within a C program/ must conform to "the specifications of a 
C-oriented decision taole language presented in section II 
of this manual. The 1 anouaae described combines aecision 
table capabilities with many of the features of C. 

DELTRANS processes one decision table at a time. It 
reads/ decodes/ and edits each line of the table. Messages 
are printed on the terminal when errors are detected. The 
decision table is output as C source code on a specified 
file. Optionally, a formatted listing may be obtained. 
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The decision logic translator is designed for use on 
the PDP-11 with the UNIX operating system and 64K bytes of 
user program storage# 

A . PURPOSE 

The purpose of DELTRANS is to provide an alternative to 
the C programmer when faced with a complex logical situa- 
tion# The preorocessor is designed to be convenient for 
preparing C programs containing decision logic tables at a 
remote terminal# A cecision Ionic table may be included 
within any C program, along with any syntactically correct C 
expressions# 

B. FUNCTIONS PERFORMED 

Briefly, DELTRANS opens and reads from the input file 
specified by the user and oreorocesses the C program con- 
tained therein. The a e f a u 1 t is input from the terminal 
itself. Source code is placed on the output file also 
specified by the user. Its default name is 'd.tab.c'. This 
file is initially opened and then closed, along with the 
input file, when oreprocessi ng is complete. Each decision 
logic table is coded as a separate subroutine in this file. 

Optionally, a formatted and thus very readable copy of 
each decision table contained in the input file may be 
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redirected to the line printer or any other file upon com- 
pletion of preprocessing. 

Additionally; the decision logic table is examined for 
ambiguous or incomplete logic* 

C. LIMITATIONS 

The Processor limitations described here are due to the 
dimensions of various arrays internal to the preprocessor. 
Most of these limitations may be relaxed by minor altera- 
tions to the preorccessor ; a consultant may be of some 
assistance in this endeavor. 

The following list of maximum values must be strictly 
adhered to avoid processing errors. 



Max i mum 


numbe r 


o f 


cond i t i ons 


= 16 


Maximum 


number 


o f 


actions = 


32 


Maximum 


numbe r 


o f 


rules = 


64 



Maximum stub length = 31 characters 

Additionally; the name of the table subroutine may be no 
more than 8 characters. 

The oreorocessor was written usina a rule mask scanning 
technique. A fundamental assumption reauired when using 
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this techniaue is that every condition is tested when 
oreparinq a mask which is# in turn» used to scan for the 
proper rule. This fact forces the programming limitation 
that each condition return a valid test regardless of the 
results of previous tests. Note that the conditions are 
tested sequentially# first to last. 

Note especially the reserved words dda, ddb/ and ddc . 
These may not be used in the logic in decision logic tables 
since the preprocessor uses these as names for the masks. 

Finally# the up arrow# except when inside quotes (single 
or double) will be read as a aefinite signal to the 
preprocessor. . .beware! 

D. ADDITIONAL BACKGROUND 

The preprocessor was written during January ana Febru- 
ary# 1977# as a thesis project by Lt. J.F. Keller and Capt. 
R.W. Roesch. 

Subroutines required by the system are as follows: 

getc putc f open printf 

exit f f 1 ush f c reat 

The VACC library routines are also required. 
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II. GENERAL INFORMATION 
A. ACCEPTABLE INPUT 

A decision logic table may occur anywhere within a C 
program; however, it is normally considered as a procedure 
and should be treated accordingly. As shown in Figure 1, 
the table itself is first recognized by the preprocessor by 
the occurrence of a left arrow ('<■') as the first character 
of any line within a C program. 

The table itself is divided into three distinct sec- 
tions, separated by the up arrow ('f'), as depicted in Fig- 
ure 1. As shown, the sections are identified as the option 
section, the condition section, and the action section. 

«- 

OPTION SECTION 
t 

CONDITION SECTION 
f 

ACTION SECTION 



FIGURE 1. Decision Table Format 
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1 


i n t 


r [61 


I 0, 


1 ,-2, -3, 


2,-3) ; 


2 


i n t 


s C61 


1-4, 


9,-7, 0, 


-4, -1 > ; 


3 


i n t 


t 16] 


1-1 , 


3,-2, -1 , 


0, 3> ; 



a 

5 

6 

7 

8 
9 

10 
1 1 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 



main ( ) 
i n t 
for 



{ 

k / 

(k = o; k<6; k + ♦ ) { 
or i nt f ( " \nT he numbers 
orintfC" \tP = 
printf("\tT = 

1 oqt ab ( k ) ; 



t o 



iiumucio <-u test are :\n"); 
%d\n\tS = %d\n", r Ik] , s IkJ ) ,* 
%d\n", t C k 3 ) ; 



rpos ( ) < 



printf("R is positive. \n"); 



1 ogt ab ( c ) 



// 



i n t 
this 



C i 

i s 



5 

4 

3 



c 3 



{ 

a comment 



i n t a ; 
char b ; 



T 

r Cc 1 
s tc 1 
t Ic 1 



0 

0 

0 



y ( 1 - 3 , 4 

y ( 1,2) 
y(l-4) -(5) 
n(2-3) ; 



) N(5) ; 
n ( 3 ,4) 



p r i n t f ( " T 
orintf("S 
o r i n t f ( " R 
rpos ( ) 

«- 



0 

0 

0 



" ) 
") 



\n 
3 5 



3 4,l; 

3 1 > 2 } 

") 3 1,2, 3, 4; 



FIGURE 2. Example Program with a Decision Logic Table 
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Each section has a specific format and although there is 
much freedom of input allowed? several rules must be fol- 
lowed as described in the followina sub-sections. 

1. The ODtion Section 

The format of the option section is relatively free? 
however several items must appear and be initialized. Docu- 
menting comments follow the rules of C and thus may appear 
anywhere within this section. In accordance with those 
rules? they must be oreceeded by a double slash ('//') or 
preceeaed by '/*' and followed by 

The possible oot ions are listed below. 



1 . 


'a' 


or 


' A ' 


• 

• 


number 


of actions 


• 

• 


r equ i red 


2. 


•c ’ 


o r 


•C ' 


• 

• 


number 


o f cond i t i ons 


• 

• 


reau i red 


3. 


' d ' 


o r 


•O' 


• 

• 


dec 1 arat i ons 


• 

• 


optional -see 


















below 


a . 


'e' 


o r 


•E ' 


• 

• 


else / 


error action 


• 

• 


r equ i r ed 


5. 


'n' 


o r 


' N ' 


• 

• 


subrout 


i ne name 


• 

• 


requ i rea 


6. 


' r ' 


or 


•R ' 


• 

• 


number 


of rules 


# 

• 


r eau i red 



If the declaration option ('d' or 'D') is used in a 
table? it must be the last ont ion used in the option section 
of that taole. All variables local to the decision table 
itself must be declared to avoid future compilation errors. 
As shown in Figure 2? the declarations must De syntactically 
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correct C declarations. DELTRANS implements this feature by 
passing untouched to the output file all code between the 
*d* (or *D*) and the up arrow at the end of the option sec- 
tion. 

Add i t i ona 1 1 y , the following options must be speci- 
fied in the format indicated: 

a. The number of conditions: 

c <number> or C <number> 

b. The numoer of rules: 

r <number> or R <number> 

c. The number of actions: 

a <number> or A <number> 

Again# as shown in Figure 2# these options may be specified 
in free form with one or more spaces between a letter and a 
number . 



Another reauired action is the name or 1 n * option. 
It must also appear before the declarations and must be of 
the following format: 

n <name> (<formal oarameters>) <tyre specif i cat i ons> ; { 
where 
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' n ' may be ' N ' . 

<name> may be from 1 to 8 characters 

< f o r m a 1 oarameters> is optional aepending upon 
required parameters. 

<type spec i f i c a t i on s> are required for all parame- 
ters dec 1 a red . 

For example* line 20 in Figure 2 names the output 
subroutine "logtab" with one parameter* "c". Compare with 
the output code in Fiqure 0 . 

The final reaui red entry in the option section is 
the else/error action. The preprocessor will physically 
code this as the final "else" action is the output code. 
The format of the else/error is an 'e' (or ’E') followed by 
any number (including zero) of blanks and tabs followed by a 
strinq of at most 31 characters followed by 'cl'. The 31 
characters must form a valid C expression or group of 
expressions. 

2. The Condition Section 

The condition section is organized as a series of 
condition lines with the end of the section indicated by an 
up a r row . 



Each condition line contains four entries: a condi- 

tion stub of up to 31 characters* an at sign ( 1 S ' ) * which 
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indicates the end of the condition stub; an optional list of 
truth values corresponding to numbered rules; and finally a 
semicolon/ which indicates the end of the condition line. 

The condition stub is copied character for character 
(maximum 31)/ up to the at sign/ directly into the appropri- 
ate internal structure. 

The format for the list of truth values is rela- 
tively free-form in that tabs/ spaces/ and newlines are 
ignored when appropriate. The default entry for each rule 
is a "don't care" or aash. To overwrite with any logic 
letter ( Y , y , N / n /*/$/-) / that logic letter is placed in front 
of a set of Parentheses containing the list of rules for 
which that loqic letter is to be entered. 

This list of rule numbers must contain at least one 
rule number and may be in either or both of two formats. 
The first format is a list of single rule numbers/ separated 
by commas/ in any cesired order. The second or "throuah" 
format uses one rule number/ a dash/ and then another rule 
number. The effect of this format is to enter the selected 
logic letter into each rule starting with the first and 
including all the rules through the last. See Figure 2 
lines 28-31 for examoles of condition lines. 

When all the logic letter overlays have been 
entered/ a semicolon is entered to alert DELTRANS that the 
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end of the truth values for the current condition has been 
found and that the preorocessor must proceed to either 
accept the next condition stub» or ( if the up arrow is found 
next f proceed to decode the action section. 

DELTRANS was constructed with the intention that it 
be used as a basis for additional work in providing decision 
loqic table processing capability. The original implementa- 
tion does not use the implicit entries ('*' and '$') in 
either completeness test i nq or in construction of the output 
code. The programmer is nonetheless strongly encouraged to 
use these entries since they help to bring out the loaic of 
the problem at hand. 

3. The A c ti on Section 

The action section is organized as a series of 
"action lines" with the end of the section indicated by a 
left arrow. The left arrow is used since the end of the 
action section is also the end of the input for the current 
table. 



Each action line contains four entries! an action 
stub of up to 31 characters! an at sign to indicate the end 
of the action stub! a list of rules for which the action is 
to be performed! and a semicolon to indicate the end of the 
action line. 
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The action stub is copied character for character 
(maximum 31) ud to the at si on directly into the appropriate 
internal structure. 

The format of the list of rules is relatively free- 
form in that/ once again/ tabs/ spaces/ and newlines are 
ignored when appropriate. The default entry for each rule 
is not to perform the current action. Thus/ to indicate the 
action is reaui red for a list of rules/ that list of rules/ 
separated by commas/ is entered. No particular order of 
rule numbers is required. See Figure 2 lines 33-37 for 
examples of action lines. 

rthen the list of rules has been entered/ a semicolon 
is input to alert DELTRANS that the end of the current 
action line has been ciscovered and that DELTRANS must per- 
form the actions reaui red to determine whether or not to 
terminate this phase of operations. 

B. PROGRAMMING TECHNIQUES 

Although any beginning programmer familiar with C, UNIX/ 
and decision logic tables should be able to construct a 
valid input decision logic table for DELTRANS/ there are 
three specific aspects of input programming that a more 
advanced proarammer should know. 
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1 . Rule Sequence 

One process by which a programmer may increase the 
average execution speed of the output execution module is by 
proper ordering of the rules in the decision logic table* 
After testing the various conditions to prepare the test 
mask# that test mask is compared with each rule in sequence. 
Thus# if the programmer will code the input decision logic 
table so that the rules will bp listed in decreasing fre- 
quency of satisfaction# the average execution time of the 
output execution module will be decreased* 

2* ELSE / ERROR Action 

The else/error rule and its associated action should 
be the subject of considerable thouaht when programming 
decision logic tables* If they are improperly used the exe- 
cution speed of the ouout module can be seriously deqraded. 
This degradation in performance results from the output code 
testing the test masks aqainst each rule mask with no match 
until the final else is found. For this reason it is recom- 
mended that the else/error action only be performed for very 
infrequent transactions. 

In the event that a proorammer is convinced that no 
else/error action/rule is needed# provisions have been made 
for a null else/error action entry* To input a null 
else/error action# the first non-blank and non-tab character 
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after the ' e ' or ' E ' in the option section should be the at 
sign. Note that a null action is not a no-operation. In 
particular^ do not use a null action for the else/error 
option if a return is really intended. A null action for 
the else/error action causes the last input rule to become 
the default action in order to avoid the last test of bit 
masks for the sake of speed. 



1 

2 TABLE SUMMARY FOLLOWS 

3 

U TABLE NUMBER 1. 



5 


numbe r of 


cond i t ions 


- 3 








6 


number of 


rules 


= 5 








7 

0 

9 


number of 


act ions 


= a 








CONDITIONS 


♦ 




RULES 


10 














1 1 


r C c J < 0 




3 


y 


y 


y 


12 


s tc 1 < 0 




3 


y 


y 


n 


13 


t tel <0 




3 


y 


n 


n 


la 














15 


ACTIONS: 












16 














17 


p r i n t f ( " T 


< 0 : ") 


3 


X 






18 


orintf("S 


< 0 : ") 


3 


X 


X 




19 


printf("P 


< 0 \n " ) 


3 


X 


X 


X 


20 


rpos ( 1 




3 








21 


**** NULL 


ELSE/ERROR 


ACTION * * * * 








22 


Table 1 is 


comp 1 e t e 


and non-amb i guous . 





y n 

n - 
y - 



x 

X 

X 



FIGURE 3. 



Example of Formatted Output 



from DELTRANS 
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3. Action Sequence 

When a particular rule is satisfied, the actions 
designated for that rule are performed in the order listed. 
If severe programming difficulties should arise from this 
restriction, the problem may be eased by listing an action 
in more than one place in the inout decision logic table. 
This will not affect the size of the output execution 
module. 

C. OUTPUT GENERATED 

DELTRANS not only generates a codeo execution module but 
also generates a formatted decision logic table for program- 
mer use in documentation and debugging. 

Fiaure 3 contains the formatted output from the example 
program in Figure 2. This formatted output is written into 
the standard output. (See section III for a discussion of 
input and output files.) In Figure 3 the table number is on 
line A. Lines 5 through 7 contain a summary of the program- 
mer input for number of rules, actions, and conditions. 
Lines 9 through 21 display the four quadrants of the deci- 
sion logic table. Line 22 specifies the else/error action 
and the last line contains the ambiguity and completeness 
message. Error messaaes are also directed to the standard 
output. See section I v for error messages and suggested 
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correcting actions. Section III contains procedures for the 
correction of errors. 

The coded execution module is written into the output 
file. The format of this code, while difficult to under- 
stand at first glance, can assist the programmer in debug- 
ging syntax errors in input decision logic tables. Figure 4 
contains the code generated by DELTRANS from the input pro- 
gram in Figure 2 . Line 20 in Figure 2 contains the name and 
parameters for the subroutine which appear in Figure 4 on 
line 19. In Figure a , line 23 contains the declarations for 
the rule masks (oda), and the test maskCddb and ddc ) . Lines 
25 through 29 initialize the test mask and rule masks. 
Lines 30 through 35 provide the code to test the conditions 
and set the test mask. The remainder of the code searches 
for a match between a specific rule mask and the test mask, 
and also contains the actions to be executed if a match is 
found. 

The ' n ' or * fv * option placed the subroutine name in the 
ouput . The 'r' and 'c' options determined the number of 
tests to be performed and the number of rule masks. The 'a' 
option merely limits the number of actions to the internal 
storage requirements in DELTRANS. The final else is used 
for the final rule. Note that the actions and conditions 
appear in the output in the same order they have in the 
i nput . 
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i n t 


r 16] 


( 0, 


t ,-2,-3, 


2 , -3 > 


i nt 


s f 6 ] 


C-4, 


9,-7, 0, 


-4,-1 > 


l n t 


t C6] 


(-1 , 


3, -2,-1 , 


0, 3} 



main ( ) { 

i n t k ; 

for C k = 0 ; k<6; k + + ) < 

pri nt f ("\nlhe numbers to test are J\n")J 
printf("\tP = %d\n\ t S = %d\n " , r C k ] , s f k ] ) ; 
printf("\tT = %d\n",tlk]); 

1 og t ab ( k ) ; 

} 

} 

rpos ( ) { / 

printf("R is positive. \ n " ) ; 

> 



logtab(c) int c ; { 

i n t a ; 
char b ; 



int dda(51 C2],ddb,adc; 
ddb = 0; ddc = 0 1 60000 ; 
dda f 0 1 f 0 ] = 0160000; dda (01 
dda CIJ CO] = 01 40000; dda C1J 
dda 1 2 ] C 0 ] = 0 1 00000; dda (2) 
dda f 3 ) C 0 ] = 01 20000; ddaC3] 
dda r4] [0] = 060000; ddaC4) 
i f C r f c ] < 0 ) { 

ddb =! 0100000; ddc = 8 
i f C s f c ] < 0 ) C 

ddb =! 040000; ddc = 8 
i f ( t tc) < 0 ) { 

ddb =: 020000; ddc =8. 
if((dda(0] f 0] 8cdb ) =-ddb 8,8. 
printf( H r < 0 ; ") ; 

p r i n t f ( " S < 0 : " ) ; 
printfCR < 0 \n ") 
else i f ( (dda Cl] CO] 8ddb)= 
printfCS < 0 : " ) ; 
printfCR < 0 \ n " ) 
else if ( (dda f 21 CO] 8ddb)= 
o r i n t f ( " R < 0 \n ") 
else if((ddaC31 [0]8ddb) = 
p r i n t f ( " T < 0 : " ) ; 
printfCR < 0 \n ") 
else < 

rops ( ) ; ] 



m = oo; 
r l ] = 020000; 
m= 060000; 

Cl ] = 0 4 0 0 0 0; 

r l ] = 0160000; 

077777 ; } 

0137777; > 

0157777; ] 

(ddaCO] Cl ] 8ddc ) = = ddc ) ( 



} 



ddb 


&& 


(dda Cl] 


C 1 ] 8ddc ) ==ddc ) C 


} 

ddb 

> 

ddb 


8,8 


(dda [2] 


C 1 ] 8ddc )= = ddc ) C 


88 


( oda 13] 


C 1 ] 8ddc ) ==ddc ) < 



> 



FIGURE 4. Example Source Code from DELTRANS 
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III. EXECUTING YOUR JOB 
A. INITIATING DELTRANS 

The command line for DELTRANS has the form of "del t rans 
followed by the incut and output filenames? if desired. 



If there are 


no f 


i 1 es 


spec i 


fied? DELTRANS will open 


the 


standard input 


for 


input 


and 


create the 


file "d.tab.c 


" for 


output • 














If there is 


only 


one f 


i 1 e narne specif i 


ed? DELTRANS 


will 


open that file 


for 


input 


and 


create the 


file "d.tab.c 


" for 


output . 














If there are 


two 


f i 1 enames 


specified? 


DELTRANS will 


open 


the first file 


for 


input 


and 


create a f i 


1 e for ouput 


using 


the second filename. 













If there are more than two filenames specified in the 
command line? the first two are used for input and output? 
and an error message is produced alerting the programmer 
that the system aetected an error in the command line. 

If the programmer wishes to keep a record of the format- 
ted table summaries and error messages? he may do so using 
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the ">" and M !" provided by UNIX for redirecting the stan- 
dard output to a file or device. 

If the code in Figure 2 was in file "fig2", then the 
command "del t rans fig2 fig4 > fia3" would generate the out- 
put code in file "figd", and redirect the table summary to 
file "fig3". Figure 4 contains the code that would be gen- 
erated in file " f i g d " and Figure 3 contains the table sum- 
mary that would be in file " f i g 3 " . 

Since the output from DELTRANS is C source code and must 
be compiled prior to execution, file names must be of the 
form "*.c”. 

B. ERROR PROCEDURES 

DELTRANS is designed to detect a number of errors during 
execution. A list of error messages is in section IV of 
this manual along with suggested programmer response to 
recover from each error. The following discussion is 
directed at classifying the errors by type. 

Ambiguity and completeness checking results in warning 
messages (program execution continues) when a redundant or 
incomplete decision logic table is encountered. Incon- 
sistent tables and actionless rules cause error message gen- 
eration and DELTRANS oiscontinues processing of the current 

I 
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table. See chapter V of the parent thesis for a discussion 
of ambiguity and completeness checking. 

File errors are discovered by the system and communi- 
cated to DELTRANS for error message generation. All file 
errors cause immediate termination of p reD r oc ess i ng . 

Errors in the option section include both numerical 
value and syntax. Value errors result when invalid numerals 
(too larae» too small* imDroperly formed) are encountered. 
Additionally* missing or duDlicate entries for required 
options cause error message generation and termination of 
table nreprocess i ng. 

Stub errors (else/error* action* and condition) are nor- 
mally caused by exceeding the limit on stub length or 
failure to use the delimiter, ’a)', in the proper place. 
Table preprocessing is terminated when a stub error is 
detected. 

Action and condition entry errors are caused by either 
syntax or invalid rule numerals. Both of these are fatal 
errors in that preprocessing of the current table is discon- 
t i nued . 

Tally errors result when the actual number of input 
actions or conditions does not agree with the number speci- 
fied in the option section. Because several arrays* inter- 
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nal to DELTRANS, have been initialized using the value in 
the option section, this error causes termination of prepro- 
cessing for the current table. 

Numerical value errors can occur in many sections of the 
input. They result from excessively large numerals, exces- 
sively small numerals, or improperly formed numerals. The 
numerals are resized by substituting the largest oermitted 
number for that usage. An error message is generated and 
DELTRANS attempts to continue execution. However, no output 
code will be generated, only error checking will be oer- 
f ormed. 

Few errors cause immediate termination of preprocessing. 
Normally DELTRANS will attempt to resynchronize the input 
stream and continue preprocessing in an attempt to generate 
a formatted table for programmer use in debugging. This 
attempt to generate assistance for the programmer will 
include not only the aeneration of a formatted table, but 
also will include the generation of some output code when- 
ever possible. However, this is forced output, generated 
only to assist in debugging. Seldom will executable code 
result when an error has been detected. 
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C. CHANGING THE INPUT DATA 

Since DELTRANS was constructed to preDrocess a file or 
input with multiple decision logic tables imbedded in that 
input/ there is no method available to the programmer to 
alter the preprocessor actions other than alter the input 
data and preDrocess the data again. For this reason the 
programmer is strongly encouraged to prepare the input as a 
file rather than enter it from the terminal. 

D. COMPILATION AND EXECUTION 

The output file generated by DELTRANS contains both the 
C code from the input prooram as well as the C code gen- 
erated by the preprocessor. In order to execute the program 
it is necessary to compile tne output program. See the 
applicable UNIX reference manual for detailed instructions 
for compiling and executina C programs. 
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IV. ERROR MESSAGES 

A user may receive one or more error messages at his 
terminal during preprocessing. They may cause immediate 
processing termination or may only be a warning to point out 
possible faulty logic. In either case/ this section may be 
used as a guide for error identification and correction. 



A 1 1 


possible DELTRANS error messages are presented here 


as they 


will appear at the ferminal / along with an explana- 


t i on and 


reguired user response. In the event any other 


messages 


appear at the terminal / the UNIX Progammer's Manual 


126] and 


the C Reference Manual [231 should be consulted. 
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A. EARNING MESSAGES 

A list of processor generated warning messages follow. 
Those not considered self-explanatory are given an error 
number for reference. 



WARNING 


* * * * * 


dupl icate 


entries 


for 


number 


o f 


actions. 


WARNING 


***** 


duo 1 icate 


entries 


for 


number 


o f 


conditions. 


WARNING 


***** 


dupl icate 


entries 


for 


number 


o f 


rules. 


WARNING 


***** 


option va 1 
line X . 


ue less 


than 


or 


equa 1 


to zero in 


WARNING 


***** 


duo 1 icate 

X . 


rules spec i f i ed 


for 


action Y line 


WARNING 


* A 0 2 * 


rules X and Y in 


table 


z 


are 


redundant . 


WARNING 


* A 0 3 * 


table Z is 


i ncomp 1 et e . 
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B. AMBIGUITY AND COMPLETENESS ERRORS 



A 0 1 : ERROR * A 0 1 * 

si stent . 


rules X and Y 


make table 


Z incon 


EXPLANATION: 


In table 


numbe r It rules X 


and Y can 


be s p e c i 


f i ed by 


the same set of 


condi t ions 


. However 



they require different actions and thus make the 
table logic faulty. Further processing on table 
Z was terminated. 



RESPONSE: 

1. Examine carefully rules X and Y. Note that 

all "don't cares" ('-') can be expanded to both 
a "y" and a "n" entry. Also a is equivalent 

to a " n " and a "S" is eauivalent to a "y". 

2. Alter rules X and Y to remove the logic 
error. 



A02: WARNING * A 0 2 * rules X and Y make table Z redundant. 



EXPLANATION: , 

In table number I, rules X and Y can be satis- 
fied by the same set of conditions. Further- 
morer they SDecify the same action and thus 
either one rule can be removed or the two rules 
combined. Table processing was not terminated 
due to this warning. 
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RESPONSE: 

Remove the redundancy by either removing one 
rule or combining the two. 



A03 : WARNING * A 0 3 * table Z is incomplete. 



EXPLANATION: 

This warning is generated to alert the user that 
the logic in table number Z does not consider 
all Dossible combinations of conditions. In 
addition, the else/error action is a null 
action. Table Drocessing was not terminated due 
to this warning. 



RESPONSE: 

1. Ensure all missinq rules would only be 
satisfied by impossible condition outcomes. 

2 . If it can not be shown that all missing 
rules are impossible, enter an appropriate error 
action. 

3. If all missina rules are impossible, iqnore 
the warning. The table outout follows 
prescribed logic. 



A 0 a : ERROR * A 0 a * no action soecified for rule X. 



EXPLANATION: 

Internal ambiguity checks reveal that rule X has 
no associated actions. 



RESPONSE : 

1. Pecheck format and logic. 

2. To imolement a true no*act ion rule, incut a 
null action and specify that action for rule X. 
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C. FILE ERRORS 



FOl: ERROR *F01* unable to open 'd.tab.c' for output. 



EXPLANATION: 

UNIX could not open the default output file 
"d.tab.c" for output. File errors cause termi- 
nation of p r eo r oc e ss i ng . 



RESPONSE: 

1. Ensure prooer format of translator call line. 

2. If there are no other program errors* contact 
a consu 1 t ant . 



F02: ERROR *F02* unable to ooen FILE for input. 



EXPLANATION: 

UNIX coulc not ooen the given file for incut. 
File errors cause termination of processing. 



RESPONSE: 

1. Ensure proper format of translator call 
line. 

2. Ensure aiven file exists. 

3. If there are no other program errors* con- 
tact a consultant. 
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F03: ERROR *F03* unable to open FILE for output. 



EXPLANATION: 

UNIX could not ooen the given file for output. 
File errors cause termination of processing. 



RESPONSE: 

1. Ensure prooer format of translator call 
1 i n e . 

<?. If there are are no other program errors 
contact a consultant. 
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D. RULE NUMBER IN ACTION OR CONDITION ENTRY 



L01: ERROR *L 0 1 * line X. 



EXPLANATION: 

The action entry on line X specifies that that 
action is to be performed for a rule number that 
is greater than the maximum number of rules 
declared in the ootion section. Processing will 
be terminated for this table if the error count 
exceeds the maximum allowable. 



RESPONSE: 

1. Check the indicated line to ensure the for- 
mat is correct. 

2 . Check the largest number in the line against 
the number of rules specified in the program 
option section. 



L02: ERROR *L02* line X. 



EXPLANATION: 

A condition entry specifies a condition is to be 
tested for an invalid rule number. Processing 
will be terminated for this table if the error 
count exceeds the maximum allowable. 



RESPONSE : 

1. Check that all rule numbers in the specified 
entry line are no larger than the maximum speci- 
fied in the option section. 
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2. Examine line X for format errors. 



L03: ERROR *L03* line X. 



EXPLANATION: 

A condition entry contains an invalid list of 
rule. Processing will be terminated for this 
table if the error count exceeds the maximum 
a l 1 owab 1 e . 



RESPONSE: 

1. Check for prooer format of line X. 

2. Ensure all rule numbers are greater than 
zero. 

3. Ensure all rule numbers are no larger than 
the maximum rule number specified in the option 
section. 

4. Ensure the second number in a list is 
greater than the first. 



LOa: ERROR *L0a* line x. 



EXPLANATION: 

An action or condition entry specifies a rule 
number that is not in the specified range. 



RESPONSE: 

Check that all rule numbers in the specified 
entry line are no larger than the maximum speci- 
fied by the program. 
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E. OPTION SECTION ERRORS 



NO 1 : ERROR * M 0 1 * initialization error. 



EXPLANATION: 

The number of rules? actions? and conditions 
must all be initialized in the option section. 
In addition they must all be greater than zero. 



RESPONSE: 

Ensure that all rules? actions? and conditions 
are initialized and in the proper format. The 
number must follow the option on the same line 
as the option. 



N 0 2 : ERROR * N 0 2 * missinq subroutine name. 

ERROR *N02* subroutine name missing from options. 

ERROR *N02* subroutine name exceeds 8 characters 

near line X . 



EXPLANATION: 

The option section for each decision logic table 
must contain the option "n" which specifies the 
name of the subroutine into which the decision 
logic table will be converted. Processing of 
the current table is halted when unable to find 
the subroutine name. 



RESPONSE: 

1. Check for proper format of the "n" option. 



99 



DELTRANS USER’S MANUAL 



2 • Ensure the name is no longer than 8 charac- 
ters and is seoarated from the parameter list by 
a space, 

3, Ensure the name is on the same line as the 

If _ M 

n • 



N0 3 : ERROR *N03* unrecoanizable oot ion ’ Q * line X. 



EXPLANATION: 

An unrecognizable ootion has been detected on 
line X. 'O' is the character DELTRANS found 
when it was exoectinq an option character. 



RESPONSE: 

1. Ensure the prooer format is used. Notice 
that no punctuation, other than soaces, is 
valid in the option section. 

2. See also error N04. 



N04 : ERROR * N 0 A * invalid numeral 'Q' near ' P ' line X. 



EXPLANATION: 

An invalid numeral has been detected on line X 
following P . 



RESPONSE: 

1. Ensure that the proper ootion format is 
used, including the circumflex. 

2. The number must follow the option on the 
same line as the option. 

3. when the logic table translator drops syn- 
chronization in the ootion section, error N03 
and M04 are reoeated while resyncroni zat ion is 
attempted. This is an indication of invalid 
option letters, format, or punctuation. 
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NOS : ERROR 


*N05* 

Y . 


i nval id 


ERROR 


* N 0 5 * 

Y. 


i n va 1 id 


ERROR 


* N 0 5 * 
to Y. 


i n v a 1 id 



number of rules line X set to 
number of actions line X set to 
number of conditions line X set 



EXPLANATION: 

The option section of the input program 
requested that either the number of actions? 
conditions? or rules exceed the maximum permit- 
ted by the translator. 



RESPONSE: 

1. A series of small? linked tables are recom- 
mended. 

2 . Check line X to ensure the option size is as 
needed . 

3. A consultant can enlarge the processor for 
special applications. 



N 0 6 : ERROR * N 0 6 * cec I arat i ons found prior to subroutine 

name. 



EXPLANATION: 

The ootion section must contain the "n" toggle 
prior to the "d" toggle to perform proper cod- 
ing. No further processing on the current table 
is attempted. 



RESPONSE: 

Edit the option section of the table and place 
the "n" toggle before the "d" toggle. 
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N07: ERROR *N07* invalid parameter list. 



EXPLANATION: 

The format of the parameter list is in error. 
The translator has recognized and accepted the 
name of the subroutine but is unable to find a 
valid list of parameters. Output has been 
forced into the specified output file as a pos- 
sible aid in debugging. 



RESPONSE : 

Locate the 
the table 
that a 



'n' toggle in the option section of 
and correct the format error. Note 
must be incl uded . 



NOS: ERROR 

ERROR 



*N08* else/error syntax line X. 

* N 0 8 * missing else/error action line X. 



EXPLANATION: 

ELSE/ERROR actions are reauired for every deci- 
sion logic table to be processed by DELTRANS. 
If no action is desired a "ed" will set a null 
action. Proper format reauires that the action 
be on the same line as the toggle "e". 



RESPONSE: 

Correct the format error on line X. 
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F. ACTION AND CONDITION STUB ERRORS 



SOI: ERROR 

ERROR 
ERROR 



*S01* invalid else/error stub line X. 
*S01* invalid action stub line X. 

* S 0 1 * invalid condition stub line X. 



EXPLANATION: 

An improperly formed stub has been detected. 
Table processing is terminated when this error 
occurs. 



RESPONSE : 

Ensure Droper format of the stub on line X/ in 
Darticular that the "a)” is in position and that 
the stub contains no more than 31 characters. 



S02: ERROR * S 0 2 * invalid condition stub line X. 



EXPLANATION: 

Emoty conaition stubs are invalid. The output 
code will fail to compile since a test of a null 
condition would be reoui red. 



RESPONSE: 

Check the format on 



line X . 
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G. ACTION AND/OR CONDITION TALLY ERRORS 



T 0 1 : ERROR * T 0 l * number of actions not as specified in 

option section. 



EXPLANATION: 

Internal checks indicate the actual number o'f 
actions input does not eoual the number of 
actions specified in the option section. Table 
processing has been terminated after forcing 
table summary output. 



RESPONSE: 

Check the number of actions and the format of 
the option statement. The output table will aid 
in locating the error. 



T02: ERRCR *T02* number of conditions not as specified 

in option section. 



EXPLANATION: 

Internal checks indicate the actual number of 
conditions input does not equal the number of 
conditions specified in the option section. 
Table processing has been terminated. 



RESPONSE: 

Ensure that the option number and the format are 
correct. See the output table for summary 
debugging assistance. 
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H. NUMERICAL VALUE ERRORS 



VO 1 : ERROR * V 0 1 * excessive value line X set to MAX. 



explanation: 

An integer larqer than any valid value in the 
translator has been detected. Further process- 
ing will be attempted. 



RESPONSE: 

1. Check integer size on line X. 

?. Ensure proper format uo to and including 
line X . 

3. See error NOS. 



V02 : ERROR *V02* invalid numeral 'O' line X. 



EXPLANATION: 

An improperly formed string of numerals has been 
encountered. 



RESPONSE: 

Ensure that all strings of numerals are in 
proper format and that no characters other than 
integers appear in the string. 



105 



DELTRANS USER'S MANUAL 



V03: ERROR *V03* line X. 



EXPLANATION: 

A non-existent rule number appears in the action 
entry on line X . 



RESPONSE: 

Check all rule numbers in action entries to 
ensure that they are greater than zero and are 
of the prooer format. 



V04: ERROR *V04* line. 



EXPLANATION: 

A non-existent rule number apoears in the condi- 
tion entry on line X. 



RESPONSE: 

Ensure all entries refer to positive non-zero 
rules. Check the format of the condition entry. 
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I. SYNTAX ERRORS 



X 0 1 : ERROR *X01* statement syntax line X. 



EXPLANATION: 

A syntax error was discovered by DELTRANS in 
line X . 



RESPONSE : 

Review the format uo to and includinq the line 
indicated. 



X02 : ERROR *X02* statement syntax line X. 



EXPLANATION: 

A syntax error was discovered by DELTRANS in 
line X. At the time of the error* DELTRANS was 
attempting to decode a condition entry list. 



RESPONSE: 

Review the format up to and including the line 
indicated. 



X03 : ERROR *X03* statement syntax line x. 



EXPLANATION: 

A syntax error was discovered by DELTRANS in 
line X. At the time the error was detected 
DELTRANS was attempting to decode an action 
entry list. 
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RESPONSE: 

Review the action list format up to and 
i ng the line indicated. 



i nc 1 ud- 
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V. GLOSSARY OF TERMS 



Action: Something to be done predicated on the 

responses to the conditions in the 
table. May be computations/ goto state- 
ment/ assignment/ etc. 

Action Entry: The lower right auadrant of the table. 

The only entry oermitted in this section 
for tables in limited entry format is an 
"X". When an "X" is placed opposite an 
action/ that action is to be taken. 

Action Line: One action from the action stub and its 

associated list of rules from the action 
entry. 

Action Statement (s) : The contents of the action stub. 

Action Stub: The lower left quadrant of the body of 

the table. Listed here are the actions 
to be taken/ which depend on the condi- 
tions in the condition stub above. 
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Comp lex Rule: 



A decision table rule which contains at 
least one "don't care" entry. 



Condition: A test or a decision to be made as part 

of the logic or processing of a problem. 
It should be stated in a form that may 
be answered "yes" or "no". 

Condition Entry: The upper right quadrant of the body of 

the decision table. This section con- 
tains responses to questions asked in 
the condition stub. 



Condition Line: 



One condition from the condition stub 
and its associated list of truth values 
for rules from the condition entry. 



Condition Statement (s) : Contents of the condition stub. 



Condition Stub: The upper left quadrant of the body of 

the decision table. All the conditions 
or tests to be made will appear in this 
sect ion. 

Contradiction: A decision loqic error in which two or 

more rules have the same combination of 
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ELSE / ERROR Rule: 



Extended Entry: 



GOTO: 



Imposs idle Rule: 



Inconsistency: 



Limited entry: 



conditions but with different actions 
specified. A synonym for inconsistent. 



[he 


rule that acts as 


a catch-all 


for 


a 1 1 


rules 


not 


spec i 


fically covered 


i n 


the 


table. 


1 1 s 


presence completes 


the 


table. 






- 





A type of decision table in which actual 
condition values are specified in the 
condition entry part of the table. 

Used for linking tables/ it is an action 
statement which references another 
table. 

A rule that due to dependency of condi- 

v 

tions is physically impossible/ e.g. c < 
10 and c > 20. 

See contradiction. 

A tyoe of decision table in which all 
conditions are stated as questions which 



have a yes 



o r no answer 



DELTRANS USER'S MANUAL 



Mi xed Entry: 



Recursion: 



Redundancy: 



Rule: 



Rule Mask: 



Simple Rule: 



A type of decision table in which both 
limited entries and extended entries 
appear. 

A synonym for looping. A conditional 
branch is made» depending on a condition 
value. 

A decision logic error in which two or 
more rules have the same combination of 
conditions with the same actions speci- 
fied. 

A s inale column of the decision table 
that shows the combination of responses 
to the conditions and the resulting or 
appropriate actions. 

A method of program coding using deci- 
sion tables* where a table matrix is 
held in storage and data matched against 
i t . 

A rule which contains no "don't care" 
entries. 
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DELTRANS USER'S MANUAL 



Table Linkaqe: A conversion by which two or more tables 

are related by means of action transfers 
(such as GOTO) from one to another. 
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APPENDIX 8 



DELTRANS SOURCE CODE 



%toker> COND ACT TLIST ALIST DIGIT NUM 
%{ 
u 



Ade f i ne 


ACTLEN 


32 


// 


max 


chars 


in act stub 


Ade f i ne 


BIGINT 


6a 


// 


max 


integer in processor 


Ade f i ne 


BLANK 


t » 












Ade f i ne 


cdnlen 


32 


// 


max 


chars 


in c dn stub 


A d e f i n e 


CRLF 


' \n 


1 










Ade f i ne 


DELIM 














Ade f i ne 


EOF 


-1 


// 


end 


0 f 


f i i 


e from getcO 


Ade f i ne 


ERRLEN 


32 


// 


max 


chars 


in else/error action 


#de f i ne 


GNC 


getc ( i 


no ) 


// 


used for program clarity 


Ade f i ne 


M A X R U L E 


6a 


// 


max i mum 


numbe r of rules 


Ade f i ne 


maxcdn 


16 


// 


maxi mum 


number of conditions 


Ade f i ne 


MAX ACT 


32 


// 


max 


i mum 


numbe r of actions 


Ade f i ne 


MAXERR 


5 


// 


max i mum 


number of non-f atal errors 



^define NULL 


'\0 


i 




^define TAB 


'\t 


t 




^define TOKN 


' <- ' 






#de f i ne TRUE 


1 






^define FALSE 


0 






i n t 


enum 


o; 


/ / 


number of errors 


i n t 


i neons i s 


false; 


// 


table inconsistency flag 


i n t 


line 


l ; 


// 


line number 


i n t 


ne x t a 


o ; 


// 


index into action structure 


i n t 


ne x t c 


o; 


// 


index into condition structure 


i n t 


nodec 


TRUE; 


// 


neaative declaration flag 


i n t 


noe 1 se 


true; 


// 


no error/else rule flag 


i n t 


nonage 


true; 


// 


no subroutine name found 


i n t 


numac t 


o; 


// 


number of actions 


i n t 


nu^cdn 


o; 


// 


number of conditions 


i n t 


num.ru 1 e 


o; 


// 


number of rules 


i n t 


Darsac t 


COND ; 


// 


parse action flag 


i n t 


pba k 


-2; 


// 


aux next character buffer 


i n t 


peek 


-2; 


// 


next character buffer 


i n t 


sumac t 


o; 


// 


check sum on number of actions 


i n t 


Sumcdn 


o; 


// 


check sum on number of conditions 


i n t 


t abno 


o; 


// 


current table number 



DELTRAMS SOURCE CODE 



int rulelMAXRULEJ; / / oointers to required actions 

/ / for each rule 

int rma s k l M A XRUL E ] 121 r // rule mask matrix 

char eeactlERRLENi) # / / error/else action 



struct { // condition stubs and condition 

char cltrtCDNLEMJ; / / entries 

char cent ry IMAXRULE1 ; 

IcstublMAXCDM]/ *cptr? 



struct < / / action stubs and action entries 

char al tr [ACTLEN] ; 

char aent ry (^AXRULE) ; 

JastubCMAXACT ] , * a o t r ; 



struct < // rule action lists 

int ac t Pt r ? 

int act 1 t rs; 

> f ree IBIGINTJ , *fptr; 



struct iobufr { / / both the input and output 

int iobfd } //buffers 

int i o 1 e f t ? 
char * i on x t n ? 
char i obuf f [5 1 21 ; 

} inbuff outbuff *inp, *outPj 



%> 

XX 

detab : 

conhalf acthalf ? 

conha 1 f : 

coniine ! 
conhalf coniine > 



coniine : 
conpart. 



cdn 1 i s t 



conpart : 

COND = {qet cdn ( ) ; > ; 



cdn 1 i s t 
c 1 i s t 



t • I 



{cdntestO;}; 



DELTRANS SOURCE CODE 



lead : 

loqltr '(' ; 



{ f i u ($?) ; ss = $2; > ! 

{ fill (52) ; $$ = $2; > ; 



cd i g : 

lead DIGIT = 
c oma DIGIT = 

cdash : 

cdig DIGIT = 

coma : 

cdig ' r ' ! 

cdash ' / ’ ; 

c 1 i s t : 

» 

I 

clist cdig ')' ! 



clist 


cdash ' 


1 ) ' 


/ 


1 og 1 t r 

'y ’ 


• 

• 


{ 


peek 


— 


1 v 


' y • 


— 


( 


peek 




1 y 


' n ' 


= 


( 


peek 




1 n 


' N ' 


r 


{ 


peek 


— 


1 n 


' * • 


— 


{ 


peek 


— 


• * 


• • » 




{ 


peek 




f - 


* $ 1 


— 


{ 


peek 


— 


• $ 



{ f i 1 1up($l,S3) ; > 



' ; > ! 
• ; > ! 
’ ; > : 
' ; > ! 
' ; > ! 
' ; > : 
• ; > ; 



ac t n a 1 f : 
a c t 1 i n e ! 
acthalf actline? 



a c 1 1 i n e : 

act Darf actlist '» 

ac t pa r t : 

ACT = {getact()/>? 



actlist : 

nlist = ( actest ( ) J > ? 



n 1 i st : 

NUM = { add ru 1 e ( $ 1 / !4as t ub [ne x t a- 1 1 ) ? 
Darsact=ALIST;> ! 

pal NUM = { add ru 1 e ( $2 / &as t ub [nex t a- 1 1 ) 
parsact = alIST ; } ; 

pa 1 : 

nlist ' / ' ; 



%% 
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actestC) { /* called at the end of each action 

entry list to determine what step 
the preorocessor should take next */ 
if ((peek=eatall()) 1= T 0 K N & & sumact < numact) 
parsact = ACT; 

else if (oeek==T0KN && sumac t ==numac t ) 
parsact = MULL; 

else 

sumerr("*T01*"»"act ions")? 



addrule (x/y) int x f y; ( /* maintans rule pointer 

list ("rule") » rule action 
list ("free")/ and action 
entries in astub */ 

int Pt r ? 
char *c ; 

if (x > numrule) badlogic("L01"); 
else if (x <= 0) bad 1 og i c ( " V 0 3 " ) ; 
else if ( * ( c — &apt r->aen t ry t x - 1 1 ) 1 = ' X ' ) ( 

*c = ’ X ' ; 

fptr -> actltrs = y? 
if (rule(xl) { 

pt r= f ot r ; 
f o t r = r u 1 e (xl ; 
while (fptr - > actpt r) 

fptr=fotr -> actptr? 
fptr -> actptr = otr! 
f Pt r = pt r ; 

) 

else 

rule(xj=fptr; 

+ + f pt r ; 

} 

else ( 

printfC WARNING ***** ouplicate rules "); 
printfC specified for action "); 
printf("%d line %d.\n"/x f line); 

> > 
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ambiqckC) { /* driver for ambiguity 

and completeness testing */ 

int n o a m b i o > c f k; 
noambig = TRUE; 

for (c = 0 ; c < (numrule -1); C + + ) { 

if (goodrule(c)) 

for (k= c+ 1 ; k < numrule! k++) { 

if C same ru 1 e ( c / k ) ) { 

amb i gt yp (c A ) ; 
noambig = FALSE; 

> 

> 

else 

noambig = FALSE; 

} 

if (goodruleCc) & & noambig) 
compl et e ( ) ; 
return(inconsis); 

> 



amb i gt yp Cc > k ) int c r k; { // determines type of 

int r! // ambiguity that exists 

for ( n - 0 ; n < numact ! n + + ) { 

if (astub [nl .aentry (cl != astub (nl . aent ry (k) ) { 

printfC" ERROR * A 0 1 * Rules % d ",++c); 
printf( H and %d make table %d " , + +k , t abno ) ; 
or intf(" inconsistent. \n M ); 
i neons i s = TRUE ? 
return; 

> 

> 

print f ( "WARNING *A02* Rules %d and %d %++c,++k); 
printfC" in table % d are redundant. Nn"/tabno); 



badloqic(c) char * c ; { / / logic error routine 

printfC" ERROR * % s * line %d.\n">C/line); 
if C++enum > MAXERR) bombC); 

> 



bombC) ( // excessive error exit 

pr i nt f C "Process i ng of table %d halted "»tabno)J 
printfC "due to error count. \n" ); 
k i 1 1 e x C ) ; 
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DFLTRANS SOURCE CODE 



cdntest ( ) < 



i f 



( (peek=eatal l())!='t' 
parsact = COND; 

else if ( pee k - = ' T ' & & sumcdn==numcdn) 

parsact = ACT; 
peek = eat a 1 1 ( ) ; 

> 

else 

sumerr("*T02*"f"conditions"); 



// called at the end of each 
// condition entry list to 
// determine what step the 
// preprocessor should take 
&& sumcdn < numcdn) 



> 



completeO f // called to determine if an 

// unambiguous table is complete. Completeness 

/ / testing of an ambiguous table is 

int c t k; // ambiguous 

k = 0 ; 

for ( c = 0 ; c < numrule; C + +) 
k =+ totrule(c); 
if (k (1 << numcdn)) ( 

p r i n t f ( " Tab 1 e % d is complete and ",tabno); 
print f ( "non-ambiguous.\n" ) ; 
i f (eeact [0) !=NULL) < 

printf( H The else/error rule for this table ") 
orintf("is suoerfluous.\n"); 

> 



> 

else if (eeac t [01 = = NULL ) 
print f ("EARNING *A03* 



{ 

table X d is 



t abno ) 



printf("incomplete.\n"); 



> ) 
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DELTRANS SOURCE CODE 



cooycode ( 1 t r ) char Itr ; { // copy code to output file 

int k / z ; // up to but excluding 1 tr 

whi le( (k = GIMC) > EOF) { 
if ( k = = 1 t r ) 

re t u rn ( TRUE ) ; // normal exit 

switch (k) { 



case 



: case ' \ 



// direct copy of quotes 



putc(k/outp ) t 

whi le((z=GNC) > EOF z 1= k) { 
if(z==CRLF) linef+f 

PUtC(2/OUto)? 



> 

if(z == EOF) thatsitO? 
putc(ZfOutp); 
b rea k ; 

case '/' : // comments are removed 

k=GNC ; 

switch (k) { 



case EOF : 

thatsitf); 


// 


EOF 




case ' / ' : 


// 


strip 


rest 


tossl ine(k); 
put c ( CRLF / out o ) 
break » 


// 

f 


of 


1 i ne 


case ' * ' : 


/ / 


strip 


to end 


c u t c om ( ) ; 
break; 
case CRLF ; 

1 i n e + + ; 


// 


of comment 


default : 


// 


normal 


case 



putcC'/'/Outp); 

outc(k,outp); 



> 

break; 



case CRLF : 


// 


count 


lines 


1 i ne + + ; 








default : 


// 


normal 


case 



putc(k,outp); 

> ) 

return(FALSE) ; 

// abnormal exit ( fail on EOF ) 

) 
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cutcom () { // strip off comments up to '*/* 

i n t c » 

while C C c = G N C ) > EOF) { 

if ( c = = C R L F ) line++; / / count lines 

else while Cc=='*') C // end of comment ? 

if ( ( c = G N C ) = = CRLF) line + + ; 
else { 

if ( c — — 1 / ' ) return; 
if (c = = EOF) thatsitO; 

> > > 

t hat s i t ( ) » //EOF 

> 



decodacr(p*max*count ) 
char *p ; 

int max* * c o u n t ? C 

i nt num ; 

i f ( *coun t 1=0) { 

printfC" WARNING ***** 
printf("for number of 



// action* condition 
// and rule option 
// number decoder 



duplicate entries "); 
% s . \ n " * p ) ; 



f 



) 



num = gobble(); // number follows option 

ifCnum < 'O' ! ' num > '9') { // if not error 

printfC' ERROR * N 0 4 * invalid ")* 

print f ("numeral ' %c ' near %c ”*num,*p); 
printfC line %C.\n",line); 
if( + + enum > maxERR) bombOJ 
peek = num; 
return; 



> 

*count = getval(num); 
i f (*count > max) { 

printfC" ERROR *N05* invalid number of %s " ,p); 
printfC "line %c set to %d.\n"*line*max); 

*count = max; 

i f (t+enum > MAXERR) bombC); 

> 

if C*count <= 0) { 

printfC "WARNING ***** option value less than "); 
printfC "or eaual to zero in line %d.\n"*line); 

> > 



eatall () C // eat up blanks* tabs* and newlines 

i nt c ; 

while ( C c =qobb 1 e ( ) ) == CRLF ) 

f 

return(c); // return the first character 
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ea t c ( ) { 

i n t c f 

i f (pbak<0 ! ! pbak 
c = ea t a 1 1 ( ) ; 

else 

c = pba k ; 
pbak = •2! 
return(c)? 



el serrorO { // decode else/error action 

// and place in eeactl] 
i f ( ( eeac t 1 0] =gobb 1 e ( ) ) == DELIM) 
eeact [0] = NULL; 

else if (eeactCOl == CRLF) { 

printf(" ERROR * N 0 8 * else/error syntax 

printf(" line %d.\n"»line); 
if (++enum > MAXERR) bombO; 
return; 

> 

else 

strcopyCERRLEN -1 ,&eeact [11 / ''el se/error") ; 
noe 1 se = FALSE ; 



f a t e r r ( h > p t r ) int h; char *Dtr; { // fatal error routine 

switch ( h ) { 

case 1 ; 



p r i n t f ( " 


ERROR 


*F 0 1 * 


unable to 


open 


") ; 


p r i n t f ( " 


' d . t ab . c ' 


1 for outout.Nn"); 






break; 












case 2 : 












o r i n t f ( '* 


ERROR 


* F 0 2 * 


unable to 


open 


" ) ; 


p r i n t f ( M 
break ; 


1 %s ' for 


i nput . 


\n"»ptr)J 






case 3 ; 












print f (" 


ERROR 


* F 0 3 * 


unable to 


open 


" ) ; 


p r i n t f ( " 


’ % s ’ for 


output 


,\n"»ptr); 







> 

pr i nt f ( M E xecut i on terminated due to file error. \n"); 
ex i t ( ) ; 

> 



// buffered eatall 
// used in yy 1 ex ( ) 

= = CRLF ! ! pbak = = T AB !! pba k = = BL ANK ) 
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fcheckC) { // check for proper options 

char *u* 

if (numrule==0 !! numcdn==0 !! numact == 0) { 

u = & ( " \ t T h e nurrber of ")/ 

p r i n t f C " ERROR * N 0 1 * initialization error. \ n " ) ; 
printf("%srules is %d.\n",u, numrule); 

pr i nt f ( "%scondi t i ons is %d . \n " , u , numc dn ) ; 
pr intf("%sactions is %d.\n",u,numact); 

enum = MAXERR + 1 ; 

> 

if (nonarre) { 

d r i n t f ( " ERROR *N02* missing subroutine name."); 

printf("\n"); 

enum — MAXERR + 1 ; 

> 

if ( noe 1 se ) { 

p r i n t f ( " ERROR * M 0 8 * missing else/error "); 
d r i n t f ( " action line %d.\n" » I i ne ) ; 
if C++enum > MAXERR) b o m b ( ) ; 

} 

if (enum > MAXERR) bomb()» 
peek = eat a 1 1 ( ) » 



fill (c) int c » { / / insert logic letter into 

if (c > numrule) bad 1 og i c ( "L02" ) ; // cent ry 

else if (c < = 0) badl ogi c ( " V04" ) ; 
else CPtr -> centrytc - 11 = peek; 



fillup ( a > b ) int a , b ; { 

/ / insert logic letter into centry list 
int i » 

if (a > 0 & & a <= b & X. b <= numrule) { 
for(i = a) i <- b; i++) 

cptr -> centryli - 1] = peek; 

> 

else { 

p r i n t f ( " I n va 1 i d condition entry: '%d-%d'\n"» a, b)» 

badl ogi c ( "L03" ) ; 

> ) 
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OELTRANS SOURCE CODE 



f i ndac r ( ) 


{ 


// 


driver for option decoding 


i n t c 


9 








while 


( (c=gobc ( ) ) > EOF ) 


< 






switch (c) C 










case CRLF : 






/ / end of line 




break; 










case ' / ' ; 






// rest of line is 




tossl ine(c) ; 
break; 






// a comment 




case ' n ' : case 


' N ' 


: // 


subroutine name follows 




namsub ( ) ; 
break; 










case 'd' : case 


•D* 


: // 


only declarations remain 




i f ( noname ) 




{ 






printfC" 


ERROR 


*N06* declarations "); 



printfC "found prior to subroutine na")l 
Drintf("me.\nFxecution terminated. \ n " ) ; 
k i 1 1 e x ( ) ; 

> 

oee k = ' t ' ; 

if (copycode (peek ) ) { 

nodec = FALSE? 
break; 

} 

thatsitO; // EOF encountered 

case 'r' : case * R * : // options 

decodacrC” rules "rMAXRULEz&numrule); 
break; 

case ' c ' ; case ' C ' : 

decodacrC "condi tions"/MAXCDfJ»&numcdn) ; 
break; 

case 'a' : case 'A' : 

decodacrC "act ions" r M A X A C T » & n u m a c t ) } 
break; 



case T ’ : 

fcheck(); 

return; 

case ' e ' : case ' E 

elserrorC); 
break; 
default : 

printfC" ERROR 



// end of section 

// check options all defined 

: // else/error action 



> i 

thatsitC); 



* N 0 3 * unrecognizable 
printfC" option '%c' line %d.\n",C/line); 
if(++enum > MAXERR) bombC); 

// unexpected end of file 
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fsuberr(k) int k ; { // error in subroutine name 

p r i n t f ( " ERROR *N02* » ) ; 

switch ( k ) { 

case 1 : 

printf(" subroutine name missing from options"); 
pri nt f (".\n\nExecut ion termi nated.Nn") ; 
k i 1 1 e x ( ) ; 
case 2 : 

orintfC" subroutine name exceeds 8 characters " ) 

orintf ("near line " ) ; 

printf("2d.\n", 1 i ne) » 

if( + + enum > N'AXERR) bomb(); 

> > 



gencode ( ) { // 

genmasks ( ) * // 

gen i n i t ( ) ; // 

gsetmask ( ) ; // 

// 

genst at s ( ) ; // 

qeneot ( ) ; // 

> 



driver for table outout 
code for declarations 
code to initialize masks 
code to test conditions 
and set mask 

output if-else statments 
output end of table 



gendubO { // output CRLF TAB TAB 

putc (CRLF/outP) » 
putc(TAB,outp); 

Putc(TAB,outo); 

) 



genelseC) ( // output else action 

gen s i g ( ) ; 

out code ("else ( " ) ; 
if (eeact(Ol) { 
gendub ( ) ; 

outcode(&eeact (01 ); 
put c ( ' ; ' r ou t p ) ; 

> 

else { 

fptr = ru 1 e (num ru 1 e 1 # 
while (fptr) { 
gendub ( ) ; 

outcode(fptr->act 1 trs) ; 
outc ( • ; ' »outp) ; 
fptr = f pt r->ac tpt ri 

> ) 

putc ( ’ > ' »outp) ; 
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geneot ( ) ( // generate final for 

putc(CRLFfOutp); // output subroutine 

putc ( ’ > ' / outp) ; 
putc (CRLF/outp ) > 



qeninitO < // output code to initialize masks 

into t 
qens i g C ) ; 

outcode("ddb=0;" ) ; 

Putc(TAB/outp); 
outcode C "ddc= "); 

ou t oc t ( 0 1 77 7 7 7 << (16 - numcdn)); 

outcode ( " ; " ) ; 

for (c=0; c < numrule; C++) { 

gensiaO ; 
outcode ( "dda ( " ) ; 
out dec (c ) ; 
outcode ( " 1 10] = ") ; 
outoct(rmask(cl (01); 
putc » out d) ; 
put c ( T A8 , ou t o ) ; 
outcode ( "dda ( " ) » 
ou t dec ( c ) ; 
outcodeC"! (1J= "); 
outoc t ( rmask l c J (1))» 
putc ( 1 ; 1 routp) ; 

> > 

genmasksO { // output mask declarations 

gens i g ( ) > 

outcode("int ddal")» 
out dec (numrul e ) ! 
outcode("l(21fddb,adc;"); 



gensigO { // output CRLF TAB 

putc(CRLF ioutp) » 
putc(TAB,outp); 
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genstats() { // output if-else statments 

i n t k > nr i 
i f (eeac t 10] ) 

nr = numru 1 e » 

e 1 se 

nr - numrule -1/ 
gens i g ( ) / 

ou t c ode ( " i f ( ( dda [ 0 ] [01 &ddb ) ==ddb && "); 

outcode(" (dda [0] ( 1 ] &ddc)= = ddc) {") '• 
fptr = rule(ll ; 
while (fptr) { 

gendub ( ) ; 

outcode(fDtr->act 1 t rs) ; 
fptr=fptr->actptr# 
out C ( ' » ' / OU t P ) / 

> 

putc ( ' > ' / outp) ; 
for ( k= 1 ; k < nr ; k+t) { 
fDtr = rule tk + 1] } 
gens i g ( ) » 

out code ( "e 1 se if((dda("); 
outdec(k); 

outcodeC"] [01 &adb)= = ddb && "); 
out c ode ( " ( dda t " ) » 
out dec ( k ) » 

out code ( " 1 (11 &ddc)==ddc) <") 7 
while ( f ot r ) { 

gendub ( ) ; 

outcode(fotr->actl trs); 
outc ( 1 ; ' /outp) ; 
fpt r=fpt r - > a c tpt r; 

> 

putc ( * > * >outo) ; 

> 

gene 1 se ( ) J 
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getact C) { // fetch and store the next action 

i n t j ; 
char *p ; 

p = &as t up Ine x t a] . a 1 t r [ 0] ? 
aotr = &as t ub [ne x t a + + ] ? 

*p = peek; 

peek - ~2 

if (*p++ 1 = DELIM) 

strcopyCACTLEN - 1 , p , " action"); 

else 

*(--p) = null; 

sumac t + + ; 

oarsact = ALIST; 

for ( j =0 ; j < numruleJ j + + ) 

aptr->aentrytj) = BLANK ; 



getcdn () { // fetch and store next condition 

i n t j ; 
char *p ; 

p = &c s t ub Ine x t c ] . c 1 t r [ 0 ) ; 
cptr = Scstub [nextct + 1 ; 

* o - peek; 
peek = -2; 

if (*p == DELIM) { 

printfC" ERROR *S02* "); 

printfC" Invalid condition stub line %d.\n"»line); 
k i 1 1 e x ( ) ; 

} 

st rcopy (CDNLEN -1 , + tp , "condi t i on" ) ; 
sumcdn + + ; 
parsact = TLIST; 
for ( j = 0 ; j < numrule; j+ + ) 
cot r*>cent ry I j 1 = 
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getval (c) int c ? { // decipher a string of numerals 

i n t num ; 
num = c ~ 'O' ; 

while ((c=GNC) >= 'O' && c <= ’9') { 

num = num * 1 0 + c - ' 0 ' ; 

i f (num > BIGINT) { 

print fC ERROR * V 0 1 * excessive value " ) » 
printf("line %d set to %d.\n"*line/ BIGINT); 
if (++enum > MAXERR) bomb(); 
whi le((c=GNC) i=BLANK R8, c!=TAB && cl=CRLF) 
if ( c == EOF ) thatsi t ( ) ; 

/ / find end of number 
if(c == CRLF) line++; 
return(BIGINT) ; 

} > 

if ( c == EOF ) thatsitO; // End-of-file 

if (c==BLANK ! ! c == TAB) return(num); 
if ( c = -CRLF ) { 

1 inett; 
return(num ) } 

) 

printfC" ERROR * V 02* inva")/ / / error exit 

printf(” lid numeral : ' %d%c ' line Xd.\n",num,C/ 1 i ne) ? 

if (++enum > MAXERR) bombC); 
peek = c; 
return(num) ; 



gobble () { // find first character other than 

intc; // a blank or tab 

while ( (c=GNC)==BLANK !! c==TAB) 

f 

if (c==CRLF) line++; 
else 

if (c == EOF) thatsitC); 
return (c ) > 



qobc ( ) ( // buffered gobble 

int c! // used in findacrO 

if (peek < 0 !! Deek==TAB S' peek==BLANK) 

c =gobb 1 e ( ) ; 

else 

c=peek ; 
peek = -2 r 
re t u r n ( c ) ; 



> 



DELTRANS SOURCE COOE 



goodrule(c) int c ; { // each rule must have at least 

i nt k ; // one action 

for ( k = 0 ; k < numactJ k + + ) { 

if (astub[kl.aentry[c]= =, X') 
return(TRUE) » 

> 

i neons i s = TRUE } 

printff” ERROR * A 0 ^4 * no actions specified "); 

printf("for rule %a.\n"»++c)» 
return(FALSE) i 



gsetnaskO < // output code to test conditions 

int Ct k; // and set test mask 

for (c=0; c < numedn; C++) { 

gens i g ( ) ; 
out code ( " i f ( " ) ; 
outcodefcstub lei .cl tr); 
out code(" ) {" ) ; 
gendub ( ) ; 

outcode ( "ddb = ! " ) ; 

outoct(k=(01 << (15-c)))» 

putc ( ' ; ' ,outp) ; 

put c ( T AB , out p ) ; 

outcode ( "ddc =& "); 

out oc t ( ■’k ) ; 

putc ( ' ; ' , outp) ; 

put c ( ' > ' , ou to ) ; 



} } 



i n i t va r ( ) 
f Pt r = 
i np = 
outp = 

> 



{ 

free? 

iinbuf.iobfd } 
&ou t bu f . i od f d ; 



// initialize variables 



killexO { // kill execution 

i n t c ; 
fflush(outp)? 

while ((c = eatall()) 1= TOKM) ; // attempt resync 

run ( ) ; 

> 

ma i n ( a rgc / a rgv ) int arqc ; char ** argv ; { 

namfi le(argc/arqv) ; 
if (copycode(TOKi\i)) { 
p roc t ab ( ) ; 
runt ) ! 

} 

fflush(outp); 

> 
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namendO { // check for end-of "name 

int c ? 

if ((c=GNC) == EOF) thatsitO* 
if (c == HLAMK ! ! c==TA8) return(-l); 

if (c==CRLF) { 

1 i ne + + ; 
return(-l ) ; 

> 

return(c)» 

> 

namfile (argciargv) // fetch names for files 

int argc t // from command line 

char *arqv U J { 
int k } 
initvarO; 
i f ( a rqc < 2 ) { 

if((k = fcreat f "d. tab. c"»outp)) = = -1) 
f a t e r r ( 1 , a rav ( 0 1 )» 

> 

else if(argc = = 2) { 

if((k = fcreat ("d. tab.c"/OutD) ) == -1) 

f at e r r ( 1 , a rqv [ 1 1 ) ; 
i f ( ( k = f ooen ( a rg v [ 1 J f i np ) ) == - 1 ) 

f a t e r r ( 2 , a rgv [ 1 ] ); 

> 

else { 

if((k = f ooen ( a r g v ( 1 ] , i np ) ) == -1) 

faterr(2,arqv [11 ); 

if((k = fcreat (argv (21 routo) ) == -1) 
faterr(3,arqvf2) ); 
if (a rac > 3 ) ( 

printff" Trash in command line : : %s\n"»arav[3]) 

> > ) 
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namsubO { // copy subroutine name to output 

int o k ? 

if ((c=gobble())-=CRLF) fsuberr(l); // missing name 

pu t c (c / ou t p ) ; 

noname = FALSE ; 

for (k=l; k < 9 ; k++) { 

if (Cc=namend()) < 0) { 

// negative return indicates end 
oarml i st ( ) J // copy parameters 

return? // normal return 

> 

putc(C/OUtp); 

} 

fsuberr(2)? // name too long 

wh i 1 e ( (c =namend ( ) ) >= 0) ? 

pa rm 1 i s t ( ) ? 

} 



outate(c) int c ? { // output octal digits 

int k ? 
if (k = C c >> 3 ) ) 
ou t a t e ( k ) ; 

putc((c%8 + ' 0 ' ) ,outo) ? 

> 

outcode(p) char *o ? { // output a string 

wh i 1 e ( * p ) 

putc ( *p++ ,outp) ? 



outdec(c) int c ? { // output a decimal 

int k ? 
if (k = c/10) 

out Pec ( k ) ? 

putc((c%10 + 'O')»outo)? 



outoct(c) int c ? { // output an octal number 

int k, t ? 
putc ('O’ ,outp) ? 
if(c>=0) outate(c)? 
else { 

putc ( ' 1 ' ,outp) ? 

c =& ( t = 077777 ) ? 

for (k = 12? k> = 0? k = k - 3 ) { 

outc(((c>>k) + ' 0 ' ),outo) ; 

C =& (t=Ct>>3) ) ? 

> ) ) 
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pact (x) int x/ { // print action stub and 

intjj / / entry list 

j = o; 

print fC"\n%-32.32s<3"/ astubtx] . a 1 t r ) ; 
w h i 1 e ( j <= (numrule - 1)) 

printfC" % c " / astubtx]. aentry[j++]); 

> 

parmlistt) < // copy parameter list to output 

i n t c ; 

while ((c=GNC) > EOF && c 1= '{') t 
putc (C/Outp) / 
if Cc==CRLF) I ine+t! 

} 

i f (c = = ' { ' ) { 

putc ( ' { Souto) ; 

putc(CRLF,outp)» 

return; 

> 

printfC" ERROR * fo 0 7 * invalid parameter list.\n")» 

thatsitC); 



pcond Cx] int x? { // print condition stub 

int j; // and entry list 

j = o; 

print f("\n% - 32. 32s<i"/ cstubtxl . c 1 t r ) ; 
whileCj < = (numrule - 1)) 

printfC" %c " / cstub txl .cent ry [ j + + ] ) ; 

> 

proctabO { // process table 

t abno + + ; 
f i ndac r ( ) ; 
if CyyparseO) 
return/ 
yyaccpt ( ) ; 
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ptable () { // driver to print table 

i n t i; 

print f("\nTA0LE SUMMARY F 0 L L 0 W S \ n " ) ; 
pr i nt f ( "\nTABLE NUMBER %d . \n" , t abno ) i 

printfC "number of conditions = % d \ n " , numcdn); 

print f(" number of rules = %d\n"f numrule); 

pr i nt f ( "number of actions = %d\n"f numact); 

print f ("\n%s%2Rs\n" , "CONDITIONS:", "RULES:"); 
for(i = Or i <= numcdn - 1; i++) pcond(i); 

print f ("\n\nACT IONS: \n") ; 

for(i = 0; i <= numact - 1; i++) pact(i); 

print f ( "\n" ) ; 

i f ( noe 1 se ) 

printfC'**** MISSING ELSE/ERROR ACTION ****"); 
else if ( eeac t [ 01 ) 

print f ("ELSE/ERROR ACTION : %s " , Reeac t [01) ; 

else 

printfC'**** NULL ELSE/ERROR ACTION ****"); 
printf("\n"); 



r e i n i t ( ) < // reinitialize vari abl es 

i nt c ; 

enum = nexta = nextc 3 numact 3 0; 

numcdn 3 numrule 3 sumact 3 sumcdn 3 0; 

noelse 3 nodec 3 noname 3 TRUE; 

i neons i s = FALSE ; 

parsact 3 COND; 

pbak - oeek 3 -2; 

fptr = free; 

for (c=0 ; c < MAXRULE ; C++) { 

rulefcl = mask (c) (0] = rmask lc) Cl) - 0; 

} 

for (c=0 ; c < BIGINT ; C++) { 

f ree lc 1 . ac t pt r = f ree fcl . ac 1 1 t rs = 0; 

} > 

run() { // driver for multiple table coding 

while ( copycode ( T0KN ) ) { 

re i n i t ( ) ; 
proctaoO; 

} 

fflush(outp); 
e x i t ( ) ; 
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sameru 1 e ( a » b ) int a, b; 
char n f p ; 
int k ; 
k = - 1 ; 

while (k++ < numcdn) 



// test if rule a and 
// rule b are identical 



n = c s t ub t k] . c en t r y t a 1 ; 
p = c s t ub ( k ) . cen t r y (b] } 
switch (n) { 

case ' - ' : 

break; 

case ' y ' : case ' $ ' ; 



return(EALSE) ; 
break; 

case ' n ' : case : 

i f (o = = ’ V ' i ! Q — — ' S ' ) 
return(FALSE); 



for(j = Or} < numrule;j++) ( 
orlist =<< ( 1 5-i ) ; 
switch ( c s t ub ( i 1 . c ent r y t j J ) { 

case ' y ' : case 'S' : 

rmask [j](0] =' orlist; 

break ; 

case ' n ' : case ' * ' : 

r m a s k [ j ] C 1 ] =! orlist; 

break ; 
default : 

rirask(j][01 =! orlist; 
rmask ( j 1 [ 1 J =1 orlist; 

} 

orlist = 1 ; 




return(TRUE) 



} 



setmask ( ) { 

int i> j • orlist; 
orlist = 1 ; 

for(i = 0; i < numcdn; i +t) 



// set rule masks 
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s t rcopy ( k 


/ p / s ) int 


k ; 


char *p , 


* 

(/> 


// copy string 


int i / 


c ; 






/ / 


from i npu t to p 


i = 0 


t 










w h i 1 e 


( + + i < k ) 


{ 








i f 


( (c=GNC) 


- - 


DELIM) 


break; 




i f 


(c==CRLF) 




1 inet+J 







else if ( c = - EOF) thatsitO; 



) 

*p 

i f 



*p++=c ; 

= null; 

( i > = k S& (c = GNC) 
if ( c - — EOF) 
p r i n t f ( " ERROR 
printf("Inval ia 
k i 1 1 e x ( ) ; 



’= DELIM) { 
thatsitO; 

*S 0 1 * " ) ; 

%s stub line % 



. \ n " t s t 1 i n e ) ; 



> > 



sumerr(n»c) char *c; { // print number errors 

p r i n t f ( " ERROR %s number of %s not " / n , c ) ; 
p r i n t f ( " a s specified in oot ion sec t i on . \n " ) ; 
print f ("\nExecut ion terminated. \n") ; 
k i 1 1 e x ( ) ; 



thatsitO { // exit for invalid end-of-file 

print f(" Unexpected END OF FILE encountered/ ")/ 
printfC' execution terminated. \n"); 
ff)ush(outp); 
e x i t ( ) ; 



tossline (c) int c ; { // toss away rest of line 

if (cl=CRLF) while ( ( c = qobb 1 e ( ) ) 1 =CRLF ) ; 

1 

totrule(n) int n; { // sum the number of simple 

intk/t; // rules in a table rule 

t = o; 

for ( k = 0 ; k < numcdn } kt + ) { 

if (cstubfkl.centrytnl == '-') 
t + t; 

} 

return ( 1 << t ) ; 
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yyaccpt () { // accepted table routines 

i n t i ; 
p t a b 1 e ( ) ; 
if ( enum ) 

return; 

if C amb i gc k ( ) ) 
return; 
setmask ( ) ; 
gene ode () ; 

> 

yyerror(s) char *s ; ( 

print f(" ERROR *X0"); 
if (parsact = = TLIST) 
printf ("2"),' 

else if (parsact == ALIST) 
p r i n t f ( " 3 " ) ; 

else 

printf("l"); 

printff"* statement syntax 
k i 1 1 e x ( ) ; 



// syntax error handler 



line %d.\n"/line); 



yy1ex(){ //scanner 

extern int yylval; 
i n t c ? 

switch (parsact) { // flag for scanner 

case TLIST 
case ALIST 
case MUM 
case DIGIT 

i f ((c=eatc()) >= '0* && c <= '9') { 
yylval - c - 'O' ; 

while ( ( c =GNC ) >= 'O' && c <= '9') { 
yylval = yylval * 1 0 + c - 'O' ; 

i f ( y y 1 v a 1 > numrule) badloqic("L09"); 

} 

if ((pbak = c) == CPLF) line++; 
else 



if ( c — — EOF) thatsit(); 
parsact = (parsact == ALIST ? NUM : DIGIT) 
return(parsact ) } 



) 

return(c); 
oe f au 1 1 ; 

ret urn (parsac t ) ; 



> > 
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